【追記：2026年6月12日】 本連載の執筆後、2026年6月12日に、米政府の輸出管理指令により、AnthropicはClaude Fable 5およびMythos 5へのアクセスを一時停止しました（同社はこの措置に異議を表明し、復旧を目指すとしています）。皮肉な話だが、「数ヶ月ごとに前提が書き換わる」という本回の主題を、この出来事自体が証明してしまった形でもあります。本文中のFable 5に関する記述は執筆時点のものとしてお読みください。本連載が扱うモデル選定・権限設計・フォールバック・運用という設計の考え方そのものは、特定のモデルの提供状況に左右されず有効です。状況は流動的であり、最新の状況は一次情報をご確認ください。
ここまで3回かけて、AIエージェントの設計図を描いてきた。モデルをタスクに応じて使い分け（第1回）、権限を絞って委任し（第2回）、状況に応じて能力を段階制御する（第3回）。設計図としては、これで一通り完成だ。
そして、内製を検討している企業にとって最も重要な話を、最後に持ってきた。この設計図の通りに作り上げた日が、コストのピークではない。 ピークはその先、ずっと続く運用の中にある。
氷山の水面下
システム開発の世界には昔から「構築費は氷山の一角」という相場観がある。AIエージェントでは、この比喩がさらに強く効く。理由は単純で、エージェントは従来のシステムより動く部品が多いからだ。モデルは数ヶ月単位で世代交代し、料金は変わり、トークンの数え方すら変わる。土台が動き続けるものの上に建っている。
図が示す通り、リリース日という水面の下に、三層の仕事が沈んでいる。観察、コスト監視、更新追従。順に見ていく。
一層目：観察 — ログは「保険」ではなく「教材」
第3回で、エージェントを状態遷移として設計した。通常運転、昇格、降格、エスカレーション。この設計が機能しているかは、ログを見続けることでしか分からない。
- 降格やエスカレーションは、月に何回、どんな引き金で起きているか
- 人間が承認を求められた操作のうち、実際に却下されたのは何件か
- インジェクションの疑いで記録された事例に、共通パターンはあるか
重要なのは、これが事故対応のための保険ではないことだ。第2回で「権限は最初に絞って、実績に応じて段階的に開ける」と書いた。その「実績」を定義するのがログだ。 数ヶ月分の観察記録がなければ、③社内×書き込みの解禁も、降格からの自動復帰も、判断する材料がない。ログを取っていないエージェントは、いつまでも初日の権限のまま運用するか、根拠なく権限を広げるかの二択に追い込まれる。観察は、信頼を積むための教材なのだ。
二層目：コスト監視 — 机上計算は、必ず実測とずれる
第1回で月額の試算をやった。あの種の計算は導入判断には必須だが、運用が始まると必ず実測とずれる。ずれる要因は、おおむね三つある。
ひとつは利用の拡大。便利なエージェントほど使われ、使われるほどトークンは増える。これは健全なずれだが、放置すると予算を静かに食い破る。ふたつめは会話の長期化。エージェントは文脈を引き継ぎながら動くため、複雑な依頼ほど内部ループが伸び、1リクエストあたりの消費が設計時の想定を超えていく。みっつめが足元の変化で、第1回で触れた通り、モデルの世代交代でトークナイザーが変わると、同じテキストでも数えられるトークン数自体が増えることがある（Opus 4.7世代で公式に最大約35%増とされ、実測ではそれを上回る報告もある）。単価表は同じでも、請求額は変わる。
対策は仕組みとしては地味だ。エージェント単位・タスク種別単位でトークン消費を記録し、月次で「設計時の想定」と突き合わせる。キャッシュのヒット率を見て、効いていなければプロンプトの構造を直す。加えて、同じモデルでも実行モードで単価が変わる例（Opus 4.8には速度優先のFast Modeが別単価で存在する）も登場しており、監視の対象は「どのモデルか」だけでなく「どのモードか」にも広がっている。それだけのことだが、やる担当者が決まっていなければ、絶対に実行されない種類の仕事でもある。
三層目：更新追従 — 昨日の最適は、今日の過剰
そして水面下の最深部が、モデル更新への追従だ。
この連載の出発点を思い出してほしい。2026年6月9日、Fable 5が登場し、最上位の単価が一夜で2倍になった。正確に言えば、Opus 4.8が値上がりしたのではなく、その上に2倍単価の新クラスが載ったのだ（サブスクリプション利用は6月22日まで追加費用なしの猶予付き、というように、影響の出方は利用形態でも異なる）。だがこの半年を振り返れば、変化はそれだけではない。フラッグシップだけでもOpus 4.6（2月）、4.7（4月）、4.8（5月）と世代を重ね、そして6月のMythosクラスの一般開放。数ヶ月ごとに、選定の前提が書き換わっている。
世代が変わるたびに、見直すべき項目は連鎖する。ルーティングの振り分け先（第1回）。新モデルの能力に合わせた権限境界（第2回）。フォールバックの切替条件（第3回）。どれも「前のままでも動く」が、前のままでは、コストか安全性のどちらかが静かに劣化していく。昨日の最適構成は、今日には過剰品質か、過小防御になっている。
しかも、更新で変わるのは性能と価格だけではない。Fable 5の導入に合わせてAnthropicは、Mythos級モデルの全トラフィックに30日間のデータ保持を義務付ける新ポリシーを発表した。用途はジェイルブレイク検知などの安全目的に限定され、学習には使われず、人間のアクセスは記録され、30日後に削除されるとされる。とはいえ、ゼロデータ保持を前提に契約していた企業にとっては、コンプライアンス要件の再確認が必要になる変更だ。モデルの世代交代は、コストや切替条件だけでなく、データガバナンスの前提まで動かすことがある。
定常業務として一覧にすると、こうなる。
| 業務 | 頻度の目安 | 連載での対応箇所 | |
|---|---|---|---|
| 挙動ログのレビュー（降格・エスカレーション事例） | 週次〜月次 | 第3回：切替条件の妥当性検証 | |
| トークン消費・コストの実測突き合わせ | 月次 | 第1回：試算の更新 | |
| 権限の段階開放の判断 | 四半期 | 第2回：実績にもとづく解禁 | |
| 新モデル評価とルーティング再設計 | 世代交代ごと（数ヶ月単位） | 第1回・第3回：選定と切替条件の見直し | |
| 禁止事項リスト・切替条件の改訂 | 世代交代ごと＋事例発生時 | 第2回・第3回 |
内製か、委託か — 天秤の最後の分銅
ここまで読んで、内製を諦めるべきだと感じたとしたら、それは本意ではない。内製が合理的な会社は、はっきり存在する。エンジニア組織を抱え、エージェントが事業のコアに関わり、この表の業務に専任を置ける会社だ。その場合、運用で蓄積される知見自体が競争力になる。
天秤の支点になるのは、結局この一点だと思う。この表の業務を、誰が、いつまでやり続けるのか。 構築は一度きりのプロジェクトとして外注も突貫もできる。だが運用は終わらない。兼任の担当者が異動したら止まる仕組みは、仕組みと呼べない。逆に言えば、設計図を描く力より、観察し続ける体制を持てるかどうかが、内製判断の本当の分水嶺になる。
そして、ここを自社で持たないと判断するのも、立派な設計判断だ。私たちunTypeはこの連載で書いてきたような選定・権限・段階制御の設計と、その後の運用を伴走する仕事をしている。自社の体制で天秤がどちらに傾くか測りかねたら、その計測から手伝えると思う。
連載のまとめ — 四つの天秤
最後に、全4回を一枚に畳んでおく。
- モデル選定の天秤：最強一択は崩れた。単価ではなく、タスク分解と振り分けの設計で総コストが決まる
- 権限設計の天秤：事故は賢さ不足ではなく権限過多で起きる。「させないこと」を先に書く。権限の境界は説得されない
- フォールバック設計の天秤：許可か拒否かの二択ではなく、段を作る。落ち方を先に設計し、外部に触れた直後は信頼度を下げる
- 運用の天秤：構築は氷山の一角。観察・コスト監視・更新追従を誰がやり続けるかが、内製判断の分水嶺
AIエージェントは、雇って終わりの道具ではなく、育て続ける同僚に近い。そう捉えたとき、本当に問われているのは技術力ではなく、組織としての続ける力なのだと思う。
参考情報
この記事をシェアする
