「最強モデル」より「強いharness」──frontier AIが“政策で止まる”時代のエージェント設計

技術ノート ｜ AIの最新動向を、現場目線で

2026年6月12日、Anthropic は Claude Fable 5 と Mythos 5 を止めた。サーバー障害ではない。米政府の輸出管理ディレクティブにより、最先端モデルへのアクセスが一夜で消えた。きっかけは「外国籍ユーザー向け」の命令だったが、運用上は国籍を識別しきれず、結果として全ユーザーが止まった。^[1]

ここで壊れたのは、Anthropic の供給だけではない。「いちばん賢いモデルさえ掴めば勝てる」という、私たちが何となく前提にしていた考え方そのものだ。3日前に「Opus の上の新クラス」として華々しく出たモデルが、3日後には触れなくなる。これは単発の事故ではなく、frontier AI が置かれた構造の変化を映している。

私たち電脳技巧集団（AI職人ギルド）は、毎日 Claude でものを作っている。だから本稿では「何が起きたか」を出発点に、開発の現場が設計をどう変えるべきか——「最強モデル」依存から「強い harness（土台）」へ——を一本の流れで書く。停止という出来事そのものの詳報は、別稿にまとめている。

関連記事 ｜ 停止そのものの詳報「最強」と紹介したAIは、3日後に消えた ──Fable 5 / Mythos 5 提供停止を、開発の現場から読む →

01一夜で消えた「最強」──"障害"ではなく"政策"で止まった

これまで、AI を使うサービスが止まる理由は決まっていた。レート制限、API のダウン、課金エラー。エンジニアはこれらに備えて、リトライやフォールバックを書いてきた。今回はそのどれでもない。政府のディレクティブで止まった。

Anthropic の公式声明によれば、根拠は国家安全保障当局による命令で、具体的な懸念の詳細は同社にも開示されなかったという。対象は外国籍ユーザーだったが、国籍をシステム側で確実に判別できないため、安全側に倒して全ユーザーが停止対象になった。^[1]つまり、コードでハンドリングできる「障害」ではなく、契約や設計の外側からやってくる「供給そのものの遮断」だ。可用性 SLA でもステータスページでも予告されない種類の停止が、現実に起きた。

3日前に「Opus の上の最強クラス」として紹介したばかりのモデルが、外部要因で世界中から一斉に消えた。主力ツールが、自分たちの都合と無関係に止まる——これが出発点だ。

02これは Anthropic 固有の話ではない──各社が「能力アクセス」を絞り始めた

「特定の会社がやらかした事故」と片づけると、本質を外す。停止の直前まで、Anthropic はむしろ高能力モデルへのアクセスを広げようとしていた。Mythos 5 は元々、サイバー防御や生物医学の防御側に限定提供する trusted access（信頼できる相手にだけ渡す）を前提にしたモデルで、Project Glasswing を通じて重要インフラの防御者へ配られていた。^[2]

そして同じ方向は、他社でも進んでいる。

• OpenAI は高能力のサイバー領域に対して Trusted Access for Cyber を運用し、Preparedness Framework に「trust-based access（信頼ベースのアクセス）」を安全策の一類型として明記している。^[3]
• Google DeepMind は Frontier Safety Framework で深刻な被害を扱うプロトコルを定め、frontier 寄りの機能を trusted testers 経由で先行公開している。^[4]

trusted access は安全策であると同時に、誰がその能力に触れられるかを決める"配信ゲート"として機能し始めている。今回の停止は、その配信ゲートに「政府」というレイヤーが乗った瞬間だった。

03frontier model は、もう SaaS ではない──供給が政策に引かれる「準インフラ」

ここから言えることは重い。最先端モデルは、もはや「契約して使う SaaS」ではなく、電力や通信に近い"準インフラ"になりつつある。準インフラの供給は、企業の経営判断だけでは決まらない。輸出管理、安全保障、地政学が直接効いてくる。

皮肉なことに、Anthropic 自身が以前から——米国の「Diffusion Rule」への意見表明などで——計算資源やモデルの輸出管理を強化する側を支持してきた。^[5]つまり今回の停止は、突然の外乱であると同時に、業界全体が招き寄せていた制度化の一コマでもある。

開発者にとっての含意はシンプルだ。「いちばん賢いモデル」は、技術的に優れていることと、明日も同じ条件で使えることが、別問題になった。性能は、供給の保証にならない。

04vendor lock-in の本丸は、API ではなく「能力アクセス／政策アクセス」

私たちは長らく、ベンダーロックインを「移行コスト」の問題として語ってきた。API が独自仕様だ、UI に縛られる、データの持ち出しが面倒だ——と。だから「API 互換」「エクスポートできる」を選定基準にしてきた。だが今回の件が示したのは、ロックインの本丸が移動したことだ。

価格でも API 互換性でもない。「その能力に、明日も触れられるか」（capability access）と、「政策・規制の側でその供給が止められないか」（policy access）——ここが本丸になった。どれだけ API がきれいでも、地域・国籍・用途・審査で供給が断たれれば、サービスは止まる。乗り換えやすさより、止まったときに事業を継続できるかが、ロックイン評価の中心に移った。

05だから「最強モデル」より「強い harness」──供給リスクを吸収する設計

ではどう設計するか。答えは、エージェントをモデル中心ではなくharness 中心で組むことだ。harness とは、モデルを動かす土台——計画・検証・記憶・承認・実行——の総体を指す。ここをプロバイダーから切り離しておけば、モデルが1つ止まっても全体は倒れない。

CAG がエージェントを組むときに置いている原則を、今回の文脈で並べると次のようになる。

• harness をモデル非依存にする。planner（計画）／checker（検証）／memory（記憶）／approval（承認）／execution（実行）を、特定プロバイダーの API から分離して持つ。
• 能力ティアでタスクを振り分ける。「使えるなら最強モデル（best if available）」と「劣化しても安全に回る経路（degraded but safe）」を、最初から両方用意しておく。
• フォールバックを"モデル差し替え"で終わらせない。本当に必要なのはその先——ツール権限、リトライ方針、評価（eval）のベースライン、ログ／差分／承認の画面、そして記憶の移植性（memory portability）まで含めて初めて「切り替えても同じ品質」になる。
• 供給停止時の BCP（事業継続計画）をエージェント運用にも持つ。誰が切り替えるのか、何が自動継続で、何が人間の承認（HITL）必須か——を決めておく。

これは CAG が一貫して言ってきた「全部を AI に任せない」「適材適所」「重要判断は人間が引き取る（HITL）」という思想と地続きだ。プロンプトを磨くより前に、供給リスクを吸収できる土台を持っているか。エージェント時代の競争力は、そこに移りつつある。

06ただし──gated release は合理的でもある。だからこそ設計側で吸収する

最後に、片側だけを責めないでおきたい。安全保障上のリスクが高い能力に対して、配布を限定する（gated release）こと自体は、一概に否定できない。すべてを無制限に公開する方が社会的に良い、と一次情報だけから断言することはできない。

ただ、その合理性と、使う側が直面する供給リスクは、両立する。だからこそ——制度の是非をどちらかに断じるのではなく——設計側でリスクを吸収するのが、現場のとるべき態度だ。最強モデルの可用性に賭けるのではなく、止まっても回る土台をつくる。それが、今回の停止が開発者に残した宿題である。本記事は政治的な評価には踏み込まず、報道・公開情報の提示にとどめる。

「最強を使う」より「最強が消えても困らない」。設計の違いを、一枚に。

観点	モデル中心設計	harness 中心設計（CAG）
依存	単一の最強モデルに集約	計画/検証/記憶/承認/実行を分離
障害想定	レート制限・outage まで	＋輸出管理・審査・用途/国籍制限
フォールバック	別モデルに差し替えるだけ	権限・リトライ・eval・承認・記憶移植まで
切替判断	止まってから都度手動	自動継続とHITLを事前に線引き
ロックインの見方	乗り換えやすさ（API互換）	止まっても事業を継続できるか
競争力の源泉	どのモデルが賢いか	止まっても回る土台があるか

※ 本記事は各社の公式声明・公開文書を、開発実務の観点から整理・論評したもの。事実関係は下記出典に基づく引用であり、CAG自身が検証したものではない（政治的評価は行わず、報道・公開された事実の提示にとどめる）。停止の長期化や再開条件、政府が問題視した具体的内容などは未確定。最新・正確な情報は必ず一次情報を参照のこと（v0・2026-06-17時点）。