9月10日の関連情報: Copilot管理権限：今回の変更点.
問い： チームはすでにAIコーディングエージェントを使っています。より難しい問いは、エージェントが何をしているかを見える化し、どこで実行されるかを制御し、そのコストを説明できるかです。2026年に、有用なエージェント導入と制御不能な導入を分けるのはガバナンスであり、モデルのスコアではありません。
読む価値のある3つの製品変更と、削除した1つの比較
8月から9月初めの3つのシグナルは、次のエージェント購入の評価方法に関わります。それぞれに出典を付け、未検証の部分を明示します。
AWS は Kiro Crew をリリースしました。 同社のKiroコーディングツール向けのオープンソース・マルチエージェントオーケストレーション層です。公式発表が述べているのは、オープンなAgent Client Protocol（ACP）を介してエージェントをオーケストレーションし、計画と実行のすべてのステップをライブで観測できる、ということです。これが検証可能な部分です。「Crewはエンタープライズ級のデータガバナンスを自動的に提供する」といったマーケティング主張は公式記述にないため、ここでは繰り返しません。
OpenClaw 2.0（バージョン2026.8.1）は、会話を中心にファイル・承認・設定・ライブのエージェント作業を一か所にまとめた、ブラウザベースのControl UIを再構築しました。リリース自体は実在し文書化されています。検証できなかった部分：この種のリリースが「マネージドサービスからの大規模なエンタープライズ移行」を推進しているという主張です。それを裏付ける独立した採用データはないため、本稿の初期草稿から削除しました。
Claude Code の上限が9月に変わりました。 複数の第三者報道が一致しています：Anthropicは「標準週次上限の恒久的25%増」を発表しましたが、発効時に一時的な50%プロモーション上乗せが期限切れとなり、ヘビーユーザーが体感したのは従来比約17%の実質減でした。公開前にAnthropic自身の発表に対してこの計算を検証できなかったため、具体的なパーセンテージは「報道ベース」として扱い、「確認済み」として扱わないでください。プロモーション枠は期限が来ると終わる、という教訓でもあります。
削除したもの： 初期草稿では、Claude Opus 5とCursorのComposer 2.5について具体的なSWE-benchのスコアを引用していました。2つのスコアは異なるベンチマーク構成から来ており、「公式」リーダーボードの数字は独立実行と一致せず、Cursor自身もベンチマークのインフレについて公表しています。同一のテスト方法に固定できないベンダー横断のスコア比較は、比較しないよりも悪いため、数字ごと削除しました。
私たちの判断：ガバナンスは「機能」ではなく、評価そのもの
ベンダーはオーケストレーション、可観測性、権限機能を出し続けます。Kiro CrewやOpenClawの承認UIはその証拠です。私たちの見解（これは測定された傾向ではなく判断です）は、チームが実際に実行する構成について、以下のチェックリストの問いに答えられない限り、これらの機能は意味を持たない、ということです。タスクがどこで実行され、何に触れ、いくらかかったかを説明できないプラットフォームは、ベンチマークスコアにかかわらずガバナンスできません。
ベンダー変更に耐えるガバナンス・チェックリスト
このリストを使って、ホスト型サービスでもオープンソースでもハイブリッドでも、あらゆるAIコーディングプラットフォームを採点してください。目的は開発者を遅くすることではなく、速度を殺さずに作業を監査可能にすることです。
1. 環境の制御。 タスクは、検査・スナップショット・ロールバック可能な管理された環境で実行されますか？ローカル専用エージェントは、認証情報が漏洩したり、特定のマシンでのみビルドが壊れたりするまでは便利です。タスクごとに隔離された開発環境を立ち上げるプラットフォームだけが、実際に強制できる境界を与えます。
2. 権限の境界。 エージェントが触れるリポジトリ・シークレット・モデルエンドポイントを定義できますか？そしてエージェント自身がそのルールを書き換えられますか？最も危険な失敗モードは悪いdiffではなく、自分自身のアクセス権限を書き換えるエージェントです。プロンプトレベルの指示ではなく、インフラレベルのゲートを探してください。
3. レビューと監査の軌跡。 すべてのタスク・ファイル変更・コマンド・モデル呼び出しが、マージ前に人間がレビューできる形で記録されますか？読めるログは事後、レビューキューは事前です。プラットフォームはdiff、テスト出力、モデルの根拠を、タスクを実行した個人だけでなくチーム全体に見せるべきです。
4. 受け入れタスクあたりのコスト。 1ドルあたりのトークンを測るのはやめましょう。レビューされ、テストされ、受け入れられた変更を得るのにいくらかかるかを測ります。トークン単価が安くてもレビューが3回増えるモデルの方が高くつきます。プラットフォームはタスク単位のコスト・並行数・モデル選択を一か所で追跡できるべきです。プロモーション枠がいつ終わるかも明示されるべきです。
5. デプロイとデータの経路。 プラットフォームを自分たちのネットワーク内で実行できますか？それは何をもたらしますか？セルフホストは、プラットフォーム自身のコンポーネント・リポジトリ・タスク記録を自組織の境界内に置くことができます。これはデプロイの条件であって、データの絶対的な保証ではありません。モデルエンドポイント、テレメトリの経路、認証情報、ログ、バックアップは依然として検証が必要です。セルフホストの制御プレーンでも外部モデルプロバイダを呼ぶ可能性があります。「コードは絶対にネットワーク外に出ない」という主張は、前提とせず検証対象にしてください。
ベンチマークは1つの問いに、ガバナンスは5つの問いに答える
独立系ベンチマークのスコアは月ごとに変わり、単一エージェントのスコアは固定ハーネスで1つのissueを解くことしか測りません。チームがその作業をどうレビューし、保護し、支払うかは測りません。このサイトの基盤であるMonkeyCodeは、まさにその理由で自らのエビデンスを公開しています：AGPL-3.0でオープンソース、タスクは管理されたサーバーサイド開発環境で実行され、プラットフォームを自ネットワーク内に置く必要があるチーム向けにプライベートデプロイの道も用意されています。この3点はすべて、リポジトリと現行のホスト利用規約に対して検証してください。無料枠もモデル一覧も変わりますし、セルフホストでも上記のデータ経路チェックは必要です。
有用な変化は、チームが発する問いです。「今月どのエージェントが賢いか？」ではなく「どのプラットフォームがワークフローの主導権を与えるか？」
評価の進め方
自分のバックログから境界のある3つのタスクを選び、候補プラットフォームと現在の環境の両方で実行します。レビュー可能な変更までの時間、人間のレビュー工数、コスト、セキュリティ/コンプライアンスのフラグを記録します。そしてガバナンスの問いを立てます：誰がそのタスクを見られるか？コードはどこで実行されたか？どんなデータがネットワーク外に出たか？明日同じ結果を再現できるか？
プラットフォームがこれらの問いにエビデンスで答えられないなら、ベンチマークスコアは無意味です。2026年に採用する価値があるAIコーディングプラットフォームは、ガバナンスをコンプライアンスの後追いではなく機能として扱うものです。
具体的な出発点として、マネージドプラットフォームモデルと既存ツールのオペレーティングモデルを比較し、次の価格変更で迫られる前にセルフホスティング・チェックリストで自環境を整理してください。