【2026年7月版】
AIエージェント時代の「作らない技術」(4) ― 頑張るだけ損になる実装と、待つ技術
公開日: 2026/07/25
読了時間: 約 13分
第1回では本家に呑み込まれるサードパーティを、第2回では長くもたない実装の仕組みを、第3回ではエージェントのループを活用する道筋を扱った。第4回では、そもそも作るべきでない実装と「待つ」という選択を取り上げる。
むやみに頑張らない。着手しない、待つ、既存機能で済ませる、汎用化しない。どれも手抜きなどではなく、やるべきかどうかを見極める技術的な判断だ。まず、頑張るだけ損になる実装を10挙げる。
頑張るだけ損になる10の実装
1. モデル固有のプロンプト最適化
モデルごとに数百行のシステムプロンプトを用意し、例示や禁止事項、出力修復や自己評価まで積み上げる。そうした特定モデル向けの作り込みは、モデルが新しくなればその一部が不要になり、過剰な指示はかえって性能を下げることさえある。一方で、ハーネスのほうは長持ちする。入力と期待結果、評価基準、失敗例、回帰テストはモデルが変わっても効く。プロンプトの文面は、いつでも書き直せる交換部品として扱われる。
2. 独自のJSON修復器と出力パーサー
以前のモデルは決まったJSON形式を安定して返せず、抽出・修復・再試行のコードが要った。だが各社が構造化出力を標準機能にし、その精度も上がり続けている。壊れたJSONを前提にした大規模な修復基盤ほど、モデル側の機能に追い越されて丸ごと不要になる。例外処理は残るとしても、独自パーサーが製品の中心に居座る理由は薄れ、足りない箇所はモデルの制約機能が埋めていく。
3. 利用量のないモデルルーター
高性能モデル、小型モデル、ローカルモデルを自動選択する仕組みは合理的に見える。しかし、月額数千円のAPI料金を削るために、経路ごとの品質を見極める判断と、継続的な評価の運用が積み増される。料金と品質を測り、実際のボトルネックが分かってから効果の大きい経路だけを分けても遅くはない。価格低下が速い市場では、複雑な最適化の完成より先に、最適化対象の価格が消えてしまう。
4. 早すぎるセマンティックキャッシュ
類似した質問へ過去の回答を再利用するキャッシュはモデル呼び出しを減らせるが、同時に古い回答や誤った類似判定、権限越境や個人情報の混入も生む。モデル更新後の不整合も避けられない。しかも、キャッシュが守ろうとする節約そのものが目減りしていく。推論価格は下がり続け、モデルが更新されるたびに、貯めた回答は前世代のものになるからだ。効いてくるのは、呼び出し量が十分に大きく、節約額が実装と障害対応のコストを上回ってからだ。
5. 先回りした複雑なRAG
文書が数十件しかない段階で、チャンク戦略や複数Embedding、リランキングや知識グラフ、階層要約までいちどに導入されることがある。モデルのコンテキスト長は急速に広がり、いまや数百万トークンを一度に読めるものもある。小規模な文書集合なら、全文をそのまま入力したほうが、複雑な仕組みより安く簡単で精度も高い。全文で評価し、次に単純な検索を試し、問題が測れた箇所だけを改善する。この順序なら無駄が出ない。先回りで複雑なRAGを組んでも、コンテキストが広がるたびに、その多くは要らなくなる。
6. 独自の長期記憶
会話をEmbedding化し、重要度を計算し、時間減衰を付け、要約して再検索する。そんな人間風の記憶を作り込みたくなる。だが、ベクトル検索は似た情報を拾えても事実の更新を判定できず、実務ではよく破綻する。結婚した利用者をその後も独身として覚え続ける、といった古い記憶の混入は、モデルではなく設計の問題だ。しかもこうした記憶は本家が標準機能に取り込みつつあり、ChatGPTは保存メモリと過去チャットの参照を備える。必要なのはたいてい、ファイルや履歴、タスクや設定といった素直な状態であって、それはSQLiteやファイルシステムで足りる。
7. 特定プラットフォーム専用プラグイン
利用者が求めていない段階で、ChatGPTやClaude、GeminiやCursor、VS Codeまで一通りの専用拡張が作られることがある。中心に安定したAPIやCLIを置き、プラグインは薄いアダプターにとどめる。実際に利用者がいるものだけを作れば、捨てるときの傷も浅い。第1回で触れたとおり、公式の接続方式そのものが短期間で入れ替わることがある。
8. 独自のワークフローDSL
AIエージェントの手順を書くために、専用YAML、グラフエディター、独自構文が自作されることがある。すでにLangGraphやCrewAI、n8n、Difyなど、この用途の基盤は出そろっている。それらを使わず一から作れば、構文だけでなくパーサーや検証器、実行エンジンやデバッガーまで保守対象になる。バージョン互換や移行ツールも自前で抱えることになる。しかも、細かな手順を外から与える設計そのものが揺れており、モデルが賢くなるほど手続き的なタスクではプロンプト一つで済むようになる。既存の基盤か通常のコードで足りる場面は、そのぶん増えている。
9. 不要なマルチエージェント化
調査担当、設計担当、実装担当、レビュー担当と名前を付けると高度なシステムに見える。だが、エージェントが増えるほど状態や通信、再試行や競合、ログやトークン消費が増える。しかもモデルが賢くなるほど、以前は分担が要った作業も一つの呼び出しで片づき、凝った構成ほど次の世代で無駄になる。一つのモデル呼び出しと通常の制御コードで足りるなら、そのほうが壊れにくい。人間の組織図をそのままソフトウェア構成へ写した設計は、たいてい重くなる。
10. 独自の汎用エージェントフレームワーク
計画や実行、観測や再試行、状態保存やツール呼び出しを統合した基盤を作りたくなる。しかし、用途がまだ一つしかない段階での汎用化は早すぎる。モデルAPI自体がツール利用、構造化出力、状態管理、長時間タスクを取り込めば、自作フレームワークは薄い互換層になる。通常のコードで一つの処理をつなぎ、同じ構造が複数の実装で繰り返されてから共通化を考えても遅くはない。「将来使いそう」は、作る理由としては弱い。
待つことは遅れではない
通常の開発では、着手を遅らせることは競争上の不利と考えられやすい。AI分野では必ずしもそうではない。三か月待つ間に、モデルのコンテキストが広がり、出力が安定し、公式APIが追加され、標準プロトコルが普及することもある。価格が下がり、OSSの実装が成熟し、競合サービスが撤退し、そもそも必要性がなかったと判明することさえある。
そのため、緊急性のない基盤実装には「着手猶予期間」を置く価値がある。アイデアが出た日にリポジトリを作らず、まず既存モデルで代用して手作業で試し、通常のコードで一度だけ動かしてみる。数週間使えば、それが繰り返し起きる問題かどうかも見えてくる。実装を考えるのは、モデルが更新されてもその問題が消えなかったときでいい。
コードは生成できても、時間は生成できない
AIによって、コードを書く費用は下がった。だからこそ、以前より多くのものを作れてしまう。しかし、作れるものが増えたことは、保守できるものが増えたことを意味しない。モデル更新のたびに挙動を確認して廃止されたAPIを置き換え、古いプロンプトを調整し、不要になった仕組みを撤去するのは未来の自分だ。
AIエージェント時代に、技術者が最も慎重に使うべき資源は自分の時間だ。GPUでもトークンでもない。モデルはさらに賢くなり、価格も下がる。今日必要に見える工夫の多くは、明日には標準機能になる。だから、現在のモデルの未熟さを補うための大工事は急がない。小さく使って通常のコードでつなぎ、問題を測って汎用化を避け、数か月待って不要になれば削除する。
そして何より、着手しないという選択そのものを、一つの技術判断として扱う。AIエージェント時代の技術力は、どれだけ複雑な仕組みを作ったかだけでは測れない。本来作る必要のなかったものへ、どれだけ自分の時間を使わずに済ませたか。そこにも、技術者の力量は表れる。
次回(第5回)は、着手前に検証すべき6つのポイントを扱う。