利益:
- AI が偽の API、安全でないコード、著作権で保護されたコンテンツを生成する可能性があることを認識し検証する機能
- ソースコードの機密性、個人データ、企業ポリシーの制限内で AI の使用を管理する能力
- ライセンスのコンプライアンス、セキュリティ、倫理に対する最終的な責任はエンジニアにあることを理解します。
モジュール試験
1. コンピューター エンジニアとして、AI コード生成ツールを使用する場合、最終的な責任は常に人間が負うべきものは次のうちどれですか?
- A) 正確性、セキュリティ、本番環境に導入されたコードのレビューとテストの最終承認 ✔
- B) 関数の最初のコード スケルトンの作成
- C) 変数名の候補リストの作成
- D) コードコメントのドラフトテキストを準備する
説明: AI。コードのスケルトン、テストドラフト、ドキュメントなどのタスクを高速化できます。ただし、生成されたコードをレビュー、テスト、承認して、それが正しく、安全で、要件に準拠していることを確認し、実稼働環境に導入するのはエンジニアの責任です。独立した検証がなければ、これを AI に委任することはできません。
2. AI があなたのために機能を生成し、幸せな方向に進んでいるように見えます。本番環境に導入する前の最善のステップは何ですか?
- A) 機能は動作しているようなので、そのまま本番環境に導入します
- B) エッジケースを含む小さな単体テストを作成して実行することで動作を検証する ✔
- C) 関数の行数だけを見る
- D) 関数の名前をより分かりやすくする
説明: 機能しているように見えることは、それが正しいことを意味するわけではありません。空の入力、ゼロ、負の値、非常に大きな値、不一致などのエッジ ケースをカバーする小規模な単体テストを作成して実行すると、関数を実際の環境に移行することなく、関数の実際の動作を検証できます。
3. AI は、あなたの言語には存在しない 'array.sortStable()' というメソッドを提案し、わかりやすく説明しました。最初に取るべき正しい行動は何ですか?
- A) AI が自信を持っていると思われるため、メソッドを直接使用する
- B) 自分でメソッドを定義し、その名前を正確に使用する
- C) 言語/ライブラリの公式ドキュメントからメソッドの存在を確認する ✔
- D) コンパイラの警告を閉じて続行します
説明: 言語モデルは、実際には存在しないライブラリ、パッケージ、またはメソッド名をもっともらしくでっち上げることができます (幻覚)。提案された各 API は、言語またはライブラリの公式ドキュメントおよび現在のドキュメントと照合して逐語的に検証する必要があります。文書に含まれていない場合は使用しないでください。
4. 会社の機密ソース コードと埋め込み API キーを公開 AI ツールに貼り付けて助けを求めたいと考えています。最も正しいアプローチはどれですか?
- A) 速度を上げるために API キーを使用してコードをそのまま貼り付けます
- B) 会社名を削除し、それ以外はすべて共有するだけで十分です
- C) コードを共有し、AI に削除を依頼する
- D) 秘密と隠されたロジックを削除し、問題を代表的な例に減らすか、制度的なツールを使用する ✔
説明: 秘密のソース コードと認証情報 (API キー、パスワード、接続文字列)。企業秘密やセキュリティの観点から危険です。秘密や隠されたビジネス ロジックを取り除き、問題を匿名/代表的な例に絞り込むか、エンタープライズ/非データ共有ツールを使用する必要があります。
5. AI は、自分が作成した検索関数の複雑さは O(n) であると言いました。ただし、コード内に 2 つのネストされたループがあります。正しいエンジニアリング動作とは何でしょうか?
- A) コードを手動で分析し、複雑さを自分で抽出し、必要に応じて測定します ✔
- B) AI が言ったので O(n) を受け入れて続行する
- C) サイクル数はパフォーマンスとは関係ないと仮定する
- D) 関数の名前を変更するだけ
説明: 時間計算量 (Big-O) は、入力が増加するにつれて演算数がどのように増加するかを示します。 2 つのネストされたループは通常、O(n^2) を意味します。 AI の複雑さの主張は、手動でコードを分析し、必要に応じて入力を増やして測定することによって検証する必要があります。この主張に依存すると、パフォーマンスについて誤った仮定が生じます。
6. AI が生成したコードは、テキストを連結することでユーザー入力を SQL クエリに直接挿入します。ここでの主な問題と適切な解決策は何ですか?
- A) 問題ありません。テキストの結合が最も速い方法です
- B) SQL インジェクションのリスクがあります。入力を分離するパラメータ化されたクエリ (準備されたステートメント) を使用する必要があります ✔
- C) クエリを大文字に変換するだけで十分です
- D) クエリを短く書くと問題が解決します
説明: ユーザー入力をクエリ テキストに直接追加すると、SQL インジェクションの脆弱性が生じます。攻撃者は入力を使用してクエリを変更できます。正しい解決策は、入力をクエリ テキストから分離するパラメータ化されたクエリ (準備されたステートメント) を使用することです。これは、AI コードで最も見落とされやすいセキュリティ上の間違いの 1 つです。
7. AI によって生成されたコードをレビューするときの時間は限られています。どの問題を優先するのが最適ですか?
- A) インデントやスペースなどの詳細のみをフォーマットします
- B) 変数名の長さのみ
- C) 論理的な正しさ、脆弱性、およびエッジケースの動作 ✔
- D) ファイルの総行数のみ
説明: コードレビューにおける最も高いリスク。これらは、論理エラー、セキュリティの脆弱性、機密情報の漏洩など、重大な損害を引き起こす問題です。形式とスタイルの問題は自動ツールで修正されます。人間の主な注意は、正確さ、セキュリティ、およびエッジケースの動作に注がれるべきです。
8. AI にバグを解決させたいと考えています。 AI が根本原因を見つけるのに最も役立つ入力はどれですか?
- A) 「コードが機能しないので修正してください」と言っているだけです
- B) ファイル名を指定するだけです
- C) エラーテキストなしで、期待される結果を言うだけです
- D) 完全なエラー メッセージ、スタック トレース、関連コード、および最小限の再現例を提供します ✔
説明: 効果的なデバッグを行うには、完全なエラー メッセージ、スタック トレース、関連するコード スニペット、およびエラーを生成する再現可能な最小のサンプルを AI に提供する必要があります。 「機能しない」という曖昧な表現により、AI は推測して包括的な推奨を行うことになります。
9. AI によって生成されたすべての単体テストは、最初の実行で合格します。この状況で無視すべきリスクはどれですか?
- A) テストはコードの現在の状態を確認することはできますが、実際の/期待される動作を確認することはできません ✔
- B) すべてのテストに合格したため、コードには完全にエラーがありません
- C) テスト数が多ければ品質は保証される
- D) テストに合格すると、補償範囲が完全であることが証明されます。
説明: テストは、意図された動作ではなく、コードの現在の (おそらくバグのある) 動作を検証している可能性があります。または、意味のあるアサーションが含まれていない可能性があり、常に渡されます。テストが実際の期待値をチェックしていることを確認するには、意識的にコードを中断し、テストが赤色に変わることを確認する必要があります。
10. AI は、問題に対して既製のコード ブロックを生成します。コードがオープン ソース プロジェクトからそのままコピーされたのではないかと疑っています。どれが正しいアプローチでしょうか?
- A) コードが機能するため何も考えずにライセンスを使用する
- B) コードのソース/ライセンスを確認し、必要に応じて書き換え、企業ポリシーに準拠する ✔
- C) 変数名を変更するだけで、問題は解決したと考えられます。
- D) ライセンスは大企業のみに関係すると仮定する
説明: AI は、トレーニング データ内の著作権/ライセンスで保護されたコードをそのまま再現できます。商用製品におけるライセンス違反は、重大な法的リスクを引き起こします。コードのソースとライセンスを確認し、必要に応じて自分の言葉で書き直し、教育機関のライセンス ポリシーに準拠する必要があります。
11. AI は、プロジェクトを直ちにマイクロサービス アーキテクチャに切り替えることを提案しました。この提案を評価する際に最も適切なエンジニアリング アプローチは何ですか?
- A) AI が示唆するため、システム全体を直ちにマイクロサービスに分割する
- B) マイクロサービスが常に最良の選択であると仮定する
- C) 実際のニーズ、負荷、チーム構造、プラスマイナスのバランスに従って提案を評価します ✔
- D) アーキテクチャの人気のみに基づいて決定を下す
説明: アーキテクチャの決定はコンテキストに依存します。マイクロサービスは、規模やチームの分離などのニーズに付加価値をもたらしますが、運用の複雑さ、分散デバッグ、コストなどのコストが伴います。実際のニーズ、負荷、チーム構造、長所と短所のバランスに従って提案を評価します。一般的なアドバイスは盲目的に従うべきではありません。
12. AI はコード用に合理化された README と API ドキュメントを作成しました。ただし、一部のエンドポイントとパラメータがコード内で一致しません。正しい行動とは何でしょうか?
- A) 文章が流暢なのでそのまま公開する
- B) タイトルだけを修正し、残りはそのままにしておきます
- C) 文書を読まずにウェアハウスに追加する
- D) 各エンドポイントとパラメータを実際のコードと比較し、一致しないものを修正します ✔
説明: ドキュメントは実際のコードを正確に反映している必要があります。間違ったドキュメントは、それを読んだ開発者に間違った使用を強います。すべてのエンドポイント、パラメーター、戻り値を実際のコードに対して検証し、不一致があれば修正する必要があります。
13. AI にコードをリクエストする場合、最高品質の出力を得るにはどの入力アプローチが適していますか?
- A) 言語/バージョン、入出力契約、制約、エラー状況を明確に提供する ✔
- B) 「実用的なコードを書いてください」と言っただけです
- C) コンテキストを何も与えずに最短のリクエストを書く
- D) コードの行数を指定するだけ
説明: 強力なプロンプト。これには、使用される言語とバージョン、入出力規約、パフォーマンスとスタイルの制約、エラー条件、および「要求されたスコープ内にのみ留まる」指示が含まれます。コンテキストのない「関数を書いてください」リクエストは汎用的であり、多くの場合、不適切なコードが生成されます。
14. AI は CI/CD (継続的インテグレーション/デプロイ) パイプラインの構成を生成し、データベース パスワードをプレーン テキストで埋め込みました。正しい修正はどれですか?
- A) 機能するためパスワードをプレーンテキストのままにしておく
- B) リポジトリに平文を置かずに、環境変数またはシークレット管理ツールを介してシークレットを移動する ✔
- C) パスワードをコメント行のみに移動する
- D) ファイル名を変更すると問題が解決します
説明: パスワードやキーなどの秘密情報を構成ファイルにプレーンテキストで書き込むと、バージョン管理の漏洩や不正アクセスのリスクが生じます。秘密;これは環境変数または特別なシークレット マネージャーによって締め出される必要があり、決してプレーン テキストでリポジトリに入るべきではありません。