ハーネスエンジニアリングの面接質問22選と回答例（AIエンジニア向け）

準備の仕方

ハーネスエンジニアリングの面接質問は、一般的なものから具体的なものへと進むのが普通です。ハーネスとは何か、どんな要素からなるか、問題をどう診断するか、効果をどう測るか。面接官が見ているのは、モデルの問題と環境の問題を区別し、検証可能な解決策を提示できるかという工学的な思考です。以下に、テーマごとにまとめた22の質問と回答例を示します。

基礎

1. エージェントのハーネスとは何ですか？

ハーネスは、モデルを除いた、AIエージェントが動作するすべての環境です。指示、ツール、実行環境、状態の保存、フィードバックのループを含みます。モデルが判断を下し、ハーネスは何を知っているか、何ができるか、結果をどう知るかを決めます。同じモデルでも、ハーネスが違えば品質は大きく変わります。

2. ハーネスエンジニアリングとプロンプトエンジニアリング、コンテキストエンジニアリングの違いは何ですか？

プロンプトエンジニアリングは一回のリクエストの言い回しを扱い、コンテキストエンジニアリングは各ステップでモデルのウィンドウに入る内容を扱います。ハーネスエンジニアリングは両方を含み、さらに文章だけでは解決できないもの、つまりツールへのアクセス、再現可能な環境、セッションをまたぐ状態、機械による検証を加えます。

3. ハーネスの5つのサブシステムを挙げてください。

指示（AGENTS.md、CLAUDE.md、skills、ドキュメント）、ツール（shell、テスト、リンター、ブラウザ、MCP）、環境（依存関係、ランタイム、Docker、worktree）、状態（PROGRESS.md、機能リスト、決定事項）、フィードバック（make check、E2E、フック、評価者）です。どれか一つが欠けると、「少し悪くなる」のではなく、ある種の失敗が体系的に起きるようになります。

4. より強力なモデルに替えても、多くの場合解決しないのはなぜですか？

多くの失敗はモデルの知能とは無関係だからです。どれほど強力なモデルでも、アクセス権のないコマンドは使えず、状態ファイルがなければ前回のセッションを思い出せず、一度も実行されていないマイグレーションが壊れていても気づけません。チーム固有の規約も推測できません。

診断

5. エージェントが CLAUDE.md に書かれたルールを破りました。どう対処しますか？

まず、エージェントがそのルールを見つけられるかを確認します。数十項目の長いファイルは、重要な内容を薄めてしまいます。入口のファイルを目次に縮め、詳細はテーマに応じて読むドキュメントに移します。ルールが重要であれば、実行可能な検査に変えます。リンターのルール、テスト、grep ガード、フックのいずれかです。そうすれば違反は機械的に検出でき、モデルの注意力に頼らずに済みます。

6. 症状からどのサブシステムが壊れているかをどう判断しますか？

既知の規約が破られるなら指示の問題です。エージェントが「やりたいができない」なら、ツールの問題です。毎回の作業が環境の修復から始まるなら、環境の問題です。新しいセッションが前回どこで止まったか分からないなら、状態の問題です。「完了」と実際の状態が一致しないなら、フィードバックの問題です。

7. ハーネスをどのサブシステムから作り始めるべきですか？なぜですか？

フィードバックから始めます。結果が使えるかどうかを機械的に答えてくれるコマンドがなければ、他のどんな変更の効果も測れないからです。その後は通常、指示、状態、環境、ツールの順ですが、順序は経験的に決まるもので、どこが最も弱いかによって変わります。

8. ハーネスの個々の要素の貢献をどう測りますか？

アブレーション実験を使います。モデルとタスクの集合を固定し、サブシステムを一つずつ切って性能の低下を見ます。ただし、より良い出発点は、層ごとに分類された失敗ログです。こちらのほうがボトルネックを早く示します。ある要素を切っても性能が落ちないことは、それが無用であることを意味しません。そのタスクでは使われなかっただけ、あるいは冗長なだけかもしれません。

指示とコンテキスト

9. 良い AGENTS.md はどう書けばよいですか？

教科書ではなく、ルーターとして書きます。プロジェクトの概要、起動方法、検証方法、完了の定義、短い必須の制約リストを含めます。詳細は別ドキュメントに置き、「決済に関わるタスクのときに読む」のような条件付きのリンクでつなぎます。ファイルは不変条件（「データは境界で検証する」）を定めるべきで、実装やライブラリの選択を一行ずつ指示すべきではありません。

10. サブエージェントは何のために使いますか？

コンテキストを隔離するためです。コードベース検索、レビュー、検証といった副次的な作業は、独立したコンテキストで実行され、結果だけを返します。メインのスレッドは汚れません。また、検査を担当するサブエージェントは実行者の推論を引き継がないため、公正な評価ができます。

11. ハーネス・デットとは何ですか？

ハーネスと現実のずれが少しずつ蓄積したものです。古くなったルール、もう動かないコマンド、存在しないモジュールを説明しているドキュメントなどです。技術的負債と同じように、気づかないうちに溜まり、エージェントの失敗という形で支払うことになります。ハーネスは一度設定して終わりではなく、定期的に見直す必要があります。

状態とセッション

12. エージェントのセッション間の健忘症にどう対処しますか？

状態をリポジトリに保存します。PROGRESS.md（現在の状態、完了した作業、ブロッカー、次のステップ）、DECISIONS.md（決定、理由、却下した選択肢）、ステータス付きの機能リスト、そして頻繁なコミットです。指示の中で開始手順を定めます。進捗ファイルを読み、環境チェックのスクリプトを実行し、アクティブな機能を一つ取り出します。

13. WIP=1 のルールは何のためにありますか？

エージェントが同時に複数の機能を始めると、状態が散らばります。どの機能も完了せず、変更が絡み合い、ロールバックも難しくなります。アクティブな機能を一つにすれば、明確な検査点、きれいなコミット、失敗後の簡単な復旧が可能になります。

14. コールドスタートテストとは何ですか？

人のヒントなしに、新しいセッションが基本的な質問に答えられるかを確かめるテストです。何のプロジェクトか、前回どこで止まったか、どの機能が進行中か、すべて正常かどうかをどう確認するか。エージェントがファイルに基づいて推測せずに答えられれば、状態のサブシステムが機能しています。

検証

15. 緑のユニットテストが機能の動作を証明しないのはなぜですか？

ユニットテストはモジュールを切り離し、依存関係をモックに置き換えるため、接続部分が見えません。インターフェースの不一致、状態の伝播の問題（スキーマは変わったのにキャッシュは古い）、リソースのリーク、設定や環境の問題がそうです。ユニットテストで見つかる欠陥は、統合テストで見つかる欠陥の一部であり、統合テストで見つかる欠陥は、E2Eテストで見つかる欠陥の一部です。

16. verification gap とは何ですか？どう計算しますか？

エージェントが完了を宣言したが、独立した検証では確認されなかったタスクの割合です。連続する10タスクを取り、それぞれについてこの二つの事実を記録します。この指標は基準値を与えます。ハーネスを改善した後、似たタスク集合で再計算します。

17. エージェント用の完了の定義（Definition of Done）はどう書きますか？

AGENTS.md に、検証可能な項目のリストとして書きます。検証コマンドが終了コード0で終わること、その場面をカバーするE2Eテストがあること、マイグレーションが適用できること、進捗が更新されていること。「完了の証拠にならないもの」、例えば「正しく見える」「ユニットテストは通っている」「自分のローカルでは動いている」も明示すると効果的です。

18. なぜエージェント自身が「完了」を付けてはいけないのですか？

モデルは自分の仕事を過大評価しがちで、しかも自己評価は判断を下したのと同じコンテキストで行われるからです。「passing」の状態は、検証スクリプトが実行結果に基づいて設定し、証拠としてコミットのハッシュを記録するべきです。

19. 独立した評価者はどう設定しますか？

要件、差分、実行結果だけを見て、実行者の推論は見ない別のエージェントまたはセッションを使います。評価基準（正確さ、アーキテクチャ、テスト、エラー処理）に沿って評価し、すべての結論はファイル、行番号、ログを参照します。別のモデルを使うのが望ましいです。死角が一致しなくなるからです。

20. アーキテクチャのルールをどう実行可能にしますか？

三つの層があります。grep ガード（速く、パターンマッチによる）、インポートグラフを理解するリンタールール（import-linter、dependency-cruiser）、CI でのアーキテクチャテストです。いずれも make check に組み込み、失敗時には非ゼロの終了コードを返し、WHY と FIX を出力して、エージェントが違反を自分で修正できるようにします。新しい検査を追加するきっかけは、コードレビューで同じコメントが二度目に出たときが一般的です。

自律作業

21. エージェントに数時間働いてもらうには何が必要ですか？

明確な目標、単調に増加する進捗指標（例えば passing の機能数）、機能ごとの時間と試行回数の予算、回帰時の自動ロールバック、そして人の手が必要な事項のリスト、つまりマイグレーション、インフラ、お金です。さらに隔離も必要です。サンドボックスや専用の git worktree を使い、エラーが実際の作業環境に影響しないようにします。

22. 単一のエージェントループでは足りないのはいつですか？ 役割のグラフはどう設計しますか？

実行者が自分で自分を検査し始め、行き詰まってしまうときです。そのときはタスクを役割に分けます。実装、レビュー、テスト、マージです。レビューはクリーンなコンテキストと評価基準を受け取り、レビューが pass のときにだけコードがマージされます。レビューが失敗すれば機能は実装に戻されます。何度も失敗した場合は、クリーンなコンテキストで最初からやり直します。これは通常、コードではなくタスクの理解に問題があることを意味します。

まとめ

ハーネスエンジニアリングの面接で最も説得力があるのは、検証可能な答えです。どのファイル、どのコマンド、どの指標か。5つのサブシステム、verification gap、そして「完了はスクリプトが判定する」という原則を頭に入れておいてください。これらのテーマはすべて、ハーネスエンジニアリングの講座で、実際のプロジェクトを通した一つの完全なハーネスとしてまとめています。