AIエージェントの開発環境では、新しいツールが次々に出る一方で、運用面の検証や制御の設計が重視されるようになりました。この変化には2つの側面があります。

1つは技術側です。「⁠ハーネスエンジニアリング」（⁠エージェントの実行結果に対して検証や制御のしくみを設計するアプローチ）と呼ばれる考え方が語られるようになりました。もう1つは人間側の変化です。ツールを追い続けることへの疲弊、いわゆる「AI疲れ」が、現場やエンジニアコミュニティで話題になっています。

この2つは無関係ではありません。ハーネスエンジニアリングも、次々に流れてくる新しい情報の1つです。新しい概念やツールが現れるたびに反応するのではなく、その背景にある課題の方に目を向ける必要があります。

ハーネスエンジニアリングの必要性

この話題のきっかけとなったMitchell Hashimotoの記事では、「⁠エージェントがミスを犯したら、そのミスを二度と繰り返さないしくみを作る」と定義しています[1]。コーディングエージェントを1つのツールとして使うとき、その外側に制御の枠組みを置いていくプラクティスです。カスタムリンター、検証ループ、CI、AGENTS.mdのような指示ファイルが構成要素になります。トークン単価の低下でエージェントの常時稼働が現実的になり、タスクの長時間化や自律運用が求められる今、この考え方の必要性が増しています。

エージェントを使う側の設計は、フェーズによって分かれます。

しかし、この技術側の整備とは別に、エンジニア自身の側にも問題が起きています。

AI疲れと生産性のギャップ

ここでいう「AI疲れ」には複数の側面があります。情報のキャッチアップ疲れ、エージェント出力のレビュー疲れ─⁠─コードの正確性だけでなく、振る舞いの確認、デバッグ、副作用の影響範囲まで含みます─⁠─、そしてツールの選択や信頼度についての判断疲れです。AIツールを積極的に使っているにもかかわらず、これらが重なって、ソフトウェアのアウトカムが頭打ちになります。ツール導入で期待した生産性と、実際のアウトカムとの間にギャップが生まれます。

デリバリー全体で見ると、コーディング速度のボトルネック解消が影響する領域は思ったより狭いものです。人間がコードを書いていたとき、コードの理解や設計意図は書く過程で自然に蓄積されていました。エージェントが書く場合、コードは生成されますが、その理解は残りません。コーディングが速くなった分、何をどう作るかの設計判断や、出力の検証・デバッグの負荷が前面に出ます。ギャップの原因はツールの問題ではなく、コーディング速度がボトルネックだという前提自体にあります。

「エージェントがアホになる」問題

ギャップにはもう1つの原因があります。コーディングエージェントをブラックボックスとして使っていることです。

中身を知らなければ、タスクごとの成果物でしか品質を判断できません。コンテキストの内部的な入れ替えで必要な情報が消えているのか、ツール選択のガイドが不足してツールが呼ばれていないのか、内部でエラーが起きているのにエージェントが黙って続行しているのか。個別のタスクでうまくいった、時短になったという成功体験はあっても、失敗したとき原因を特定する手段がありません。

「モデルが悪い」「⁠プロンプトが悪い」「⁠エージェントの性能が劣化した」という声がコミュニティでしばしば上がります。実際に障害や性能低下が起きている場合もありますが、中身が見えなければそれすら確認できません。原因を切り分けられないまま、問題とは別の箇所の最適化に時間を費やすことになります。

作って学ぶAIエージェント

この状態を抜けるために、筆者はAIエージェントを小さく手で作ってみるアプローチを取っています。作ることで初めて答えが出る問いがあるからです。

コンテキストはどう管理され、いつ入れ替わるのか。ツール呼び出しはどう組み立てられ、どこで失敗しうるのか。エージェントはどの情報を見て次の行動を選んでいるのか。これらは、ドキュメントを読むだけでは腑に落ちません。数百行のコードを自分で書いて動かす方が、構造を把握できます。

それができると、前述のような、会話上には現れない内部エラーが存在すること自体を把握でき、何を心配すべきかの線引きができます。プロンプト設計、コンテキスト設計、ハーネスといったプラクティスも、分解して評価できるようになります。

この線引きができると、なぜ情報に振り回されるのかが見えてきます。AI周辺の情報が溢れるのは、1つの課題に対して解決策（新モデル、新ツール、新フレームワーク）が無数に生まれるからです。しかし課題側─⁠─先ほど挙げたような、エージェント内部の動作原理にかかわる問い─⁠─は数が限られています。課題側にフォーカスすれば、新しいツールが出ても自分の基準で必要性を判断できます。

この考え方を実践するための書籍として、『⁠作って学ぶAIエージェント』を執筆しました。特定のフレームワークやLLMのAPIに依存せず、TypeScriptでツール呼び出しから思考ループまでを自分で組み上げます。フレームワークの内側で何が起きているかを手で確かめ、エージェントの動きを自分の言葉で説明できる状態を目指す内容です。