最近のAIコーディングエージェント周りの話
03/15 19:47 2026
03/16 08:14 2026
はじめに
最近のAIコーディングエージェント周りの個人的興味メモ
ハーネスエンジニアリング
「ハーネスエンジニアリング」という言葉をAI・ソフトウェア文脈で最初に使ったのはMitchell Hashimotoで、このブログが元ネタだと思う。
I don't know if there is a broad industry-accepted term for this yet, but I've grown to calling this 'harness engineering.' It is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.
業界で広く認められている名称がまだあるのかは分かりませんが、私はこれを「ハーネス・エンジニアリング（安全装置の設計）」と呼ぶようになりました。これは、エージェントがミスをしたときはいつでも、そのミスを二度と繰り返さないための解決策を時間をかけて構築していくという考え方です。
gogcli入れるか迷っていたところに公式サポートはない公式ツールという謎の立ち位置でリリースされたGoogle Workspace CLIのリリースをきっかけに、昨年頭にうまくいかずやめていた開発以外の業務システム自動化を試している。
MCPが出てきたばかりの頃にGoogle Calendar MCPで仕事稼働管理をさせていたんだけど、ものすごいオーバーヘッドがあって、フィードバックサイクルを回すのが苦痛だった。
やはり業務システムの癖に合わせてスキルをチューニングする幅がある。でもこれをエンジニアリングと呼べるかというとそうでもない。雑に作らせて、筋の悪いアプローチはやめさせて、実践投入して失敗させて改善させるという繰り返し。これは現場の数だけやる必要がある。ただ一方でモデルの進化によってその工数は激減するし、ミクロな自動化は専門性もクソもなくAIに投げて、振る舞いダメなら改善促せば終わる世界だなと思う。
とはいえこれがクラウドから障害を検知してコードベースにPRを送る仕組みならある程度専門性というか、IT知識がないと大変なことになる。Amazonもここら辺試しているっぽく、一方で障害も起きており興味深い出来事だと感じた。
プロジェクトとか業務に合わせてハーネスをチューニングする仕事はAI時代の新しい仕事だなとはおもう。
運用とLLM
LLMと障害調査はかなり相性がいいと思っている。これはろくにo11yの設定をしてなくても最低限システム間で一意なリクエストIDを振っていれば、簡単にクエリで紐付けて統合し、一覧生成ができる。AIコーディングエージェント上でawscliを動かせば、コードの修正提案まで一気通貫でできる。DBもポートマッピングしたら、さらに幸せになれる。何が幸せって運用、障害調査の効率化は人を救うからね。
変更障害率って一瞬でAIで修正できる仮定に基づくと、ミッションクリティカルでない機能はある程度先出リリースも可能なのかなとも思ったり。まぁこういう考えはあまり好まない人多いけどね。
AIコーディングエージェントの提供する仕様駆動機能
これはあくまでツールが提供する仕様駆動開発の話。自分はKiroしか使ったことがないのでその前提で話す。というかここに書くのは仕様駆動というよりKiroの問題な気もする。
自分はこの記事にかなり共感した。
自分は
- 人間がシステム概要を理解するためでに仕様書は必須(ステークホルダーが多いほどその価値は高まる)
- 開発は仕様ドリブンであるべき
ただAI仕様駆動ツールは発展途上で出力するドキュメントは永続的な仕様書として使うには全面書き換えが必要。これは現状実装判断まで要件として展開するため、その線引きを人間画する必要がある。これは形式言語を自然言語にしてレビューをしているような冗長さがある。永続的なドキュメントとして管理すると、コードとドキュメントの両方が詳細実装を持っており二重管理となる。
すでに実装やテストの方針が決まっているプロジェクトに置いて、作るべき実装は明確であり、そのゴールに向かってプランモードで実装する。仕様は別途Agentメモリーとは別の領域に格納するのが良い。AI駆動ツールの出力するプランやspecは永続的なドキュメントとは呼べず(これは基本設計と詳細設計の両方が一緒くたにされており、同期を取る作業が煩雑になりやすい)
上記のZennの記事は、以下のような暗黙の前提もあるように思う
-
開発者がコードを読める
-
LLMの出力を評価できる
-
いざ実装に入ったら市場の要件が変わっている
-
技術的に実現不可能な箇所が見つかる
みたいなことがあってアジャイルソフトウェア宣言には、包括的なドキュメントよりも動くソフトウェアってのがある。ただ仕様駆動はそこまでガチガチな仕組みではなくて、間違えに気づいたら仕様に戻ればいいくらいのスタンス。
仕様の永続化先をドキュメントにするとつらみとしては以下が出てくる
- 生成されたSpecのレビューが必要
- 仕様と実装の2重管理が必要
自分はこの生成されたSpecに問題があると思っている。LLMが膨らませた仕様は以下の問題がある。
- ユーザー固有の文脈が一般論に希釈されたもので社内とか現場のナレッジから離れているケースが多い
- テスト実装が冗長になりがち
1.に関しては、DynamoDBを使っているとDAXというかなりハイトラでない限り使わないサービスを勧めてきたりする。ちなみにこれはコンテキストに個人ブログのリプレースと入れててこの始末。まずそこに判断を要求している時点で負けだと思う。
2.に関しては、タスクごとに場当たり的にテストがある。つまり全体通したテスト戦略がないので冗長さの極みになる。
ステアリング頑張ればここら辺がこなれてくるのかな？
余談
compactionが起きるようなロングランの実装では最初に立てたプランを永続化しないとcompactionで実装計画や受け入れ条件を忘れる。なので外部化する手段としてドキュメント化は有効。
記事にある通りこういう形でドキュメントというかTODOを出力させて、長いタスクをやり切れた(Apple公証審査周りのタスク)ことがあるのでおすすめ。
shuntaka.dev
This site uses Google Analytics.