#AIが判断しお金を動かす経済構造変革# 「AIが経済活動の主体へと加速」する時「金融の仕組みをどう作り替えるのか」としてWeb3見るとおもろいぞ、来週のToken2049 SIngapore。例年のように知見シェアしていきますがまずは予言。 Cryptoは技術→権益構造に争点は移っていて、顧客との接点・資産の所有・行動の責任を誰が握るか。と見ると以下の６つが大事 ① 金融機関による「市場そのもの」の再設計 ② AIの「経済主体化」 ③ 普及の鍵となる「顧客の入口」 ④ 予測市場の「情報インフラ化」 ⑤ AIへの委任に伴う「所有とプライバシー」の再定義 ⑥ 既存金融への接続と、既存権力からの独立の緊張 これを象徴する要チェックの登壇企業・人物が割とそろってて ① Nasdaq／Adena Friedman、BlackRock／Nikhil Sharma 株式などのトークン化（tokenization）、常時取引、決済の変革。金融機関が暗号資産を買う段階から、市場の仕組みを変える段階への移行 ② NEAR／Illia Polosukhin、Base／Jesse Pollak AIがデータを買い、他のAIに仕事を発注。その実現を支える財布・権限・責任の設計 ③ Robinhood／Johann Kerbrat、Privy／Henri Stern いつものアプリで持ち、払い、運用できる金融。技術の普及を左右する、顧客接点と使いやすさ ④ Polymarket／Shayne Coplan 人々の判断を、更新され続ける確率として集約。AIの情報収集や意思決定につながる可能性 ⑤ Intelligent Internet／Emad Mostaque、NEAR／Illia Polosukhin 資金・判断履歴・AIとの対話を、誰に預けるか。「自分のAIを所有する」の具体的な意味の検証 ⑥ The Network State／Balaji Srinivasan、World Liberty Financial／Eric Trump 金融・国家への接続で進む普及と、既存の権力からの独立。同じCryptoに同居する、異なる未来像 シンガポールいらっしゃる方タイミングあえばキャッキャいたしませう #Token2049#

先日の経営者の異業種交流会 ChatGPT広告の話題が多かった 金を出しても　「おすすめ」には入れてもらえない それでも200日で　年換算1500億円規模に 金で買えないものに　なぜこれだけ金が集まるのか ChatGPT広告 2026年2月に米国でテスト開始　 今は日本の事業者も直接出稿できる 実はこの広告が売っているのは　推薦枠じゃない 答えの「横」に置く場所 からくりを順番に見ていく ①分離された仕組み ・広告配信の仕組みと　回答を作る仕組みは別々 ⇓ ・広告主は回答の中身を書き換えられない ⇓ ・表示される順番も動かせない ⇓ ・買えるのは枠だけ ②連れてくる客が違う ・検索は「探している人」を連れてくる ⇓ ・AIは「もう決めかけている人」を連れてくる ⇓ ・数は減る ⇓ ・比較検討が終わった状態で来る ③「おすすめ」に入る条件 ・「高品質」「実績多数」では判断されない ⇓ ・誰に　どんな場面でおすすめすべきかが書いていないから ⇓ ・数字　対象者　期間　固有名詞　条件 ⇓ ・第三者が確かめられる具体だけが拾われる ④測っていない会社の誤解 ・アクセス解析の参照元に ⇓ ・分けて見ていなければ流入はゼロ扱い ⇓ ・もう来ている客を「成果なし」と判断する つまりこういう循環 具体情報を置く → AIが引用する → 決めかけた客が来る → 実績が増えてまた引用される ただし全業種に効くわけじゃない 効くのは　客が迷う時間が長い商売 金額が大きい　失敗したくない　人に相談してから決める そういう商材ほど　AIの答えが判断材料になる 逆に「今すぐ」「近い」で決まる商売は　まだ地図の勝負 そして広がる速度がこれ 2026年2月　米国でテスト開始 2026年　日本で配信開始　事業者向けに出稿を開放 2026年8月末　開始200日未満で年換算1500億円規模 2026年9月　提供国60カ国超 Google広告が25年かけて作った市場 そこへAIは　1年で入ってきた そして今はまだ　金を払わずに「おすすめ」に入れる 枠は買える 「おすすめです」は買えない あなたの会社　広告を出す準備はしても　おすすめされる準備はできてる？

Y Combinator「AI時代のスタートアップアイデアの選び方」 ■ 考えすぎるのをやめる 起業 of 初期段階において、完璧なアイデアを求めて熟考しすぎることは最大の罠の一つです。アイデアは頭の中で抽象的に考えても導き出せず、現実に接触して顧客のフィードバックを得ることで初めて構築すべきものが理解できます。また、自分がその領域に相応しい完璧な創業者なのかと自問自答し、挑戦を躊躇してしまうのもよくある失敗です。創業者と市場の適合度は重要ですが、専門分野での長年の経験がなくても、実際に行動を起こして学習を重ねることで成功への道は開けます。 ■ 1つのアイデアにコミットする 複数のアイデアを同時に進めると、ノイズの多い不正確なデータしか得られず、正しい判断ができなくなります。多くの選択肢を抱えすぎると、どのアイデアからも真のシグナルを受け取れず、良いアイデアを早く諦めたり悪いアイデアにしがみついたりします。1つのアイデアに深くコミットするためには、他のすべての選択肢を明示的に排除して退路を断つ必要があります。顧客に対してピボットを宣言し、メールやウェブサイトを含めたすべてを新しいアイデアへと移行させ、全身全霊で集中する環境を整えるべきです。 ■ 顧客の課題に深く入り込む アイデアを深く掘り下げているか判断する基準は、自分が顧客のビジネスを実際に運営できるほど熟知しているかどうかにあります。顧客が直面する日々の危機や、解決のためにお金を支払う具体的な痛みを把握し、その課題について講義ができるレベルに達しなければなりません。その境地に達するためには、数多くの顧客と対話し、時には自分自身でその業務を体験してみることが最も効果的です。何百人もの話を聞くことに執着しすぎず、ニーズの把握、製品のリリース、さらなる深い理解と改善という迅速なループを回し続けることが大切です。 ■ AI時代における優れたアイデアの3条件 AI時代における優れたアイデアは、まず現在のフロンティアモデルでかろうじて動作し、モデルの進化とともに確実に性能が向上する境界線上に位置するものであるべきです。次に、単なるソフトウェアを提供するのではなく、特定の業界に特化して成果そのものを顧客に販売する垂直統合型であることが求められます。ソフトウェア自体の構築コストがゼロに近づく中、真の価値は顧客の信頼や独自の規制許可、そして成果の所有権へと移行していきます。平凡なアイデアも野心的なアイデアも必要な労力と時間は変わらないため、業界の仕組み自体を書き換えるような最も野心的な挑戦を目指すべきです。 ■ 失敗したとしても得られる果実 たとえ選んだアイデアが最終的に失敗したとしても、挑戦を始めた時点よりも遥かに前進した場所に立つことができます。その過程で、本当に解決すべき緊急性の高い課題が存在するのか、あるいは自分自身を無理に納得させていただけなのかを示す明白な顧客データが得られます。この確かなデータこそが、次の挑戦や方向転換を行うための強力な確信の土台となります。創業者は往々にして表層的な痛みに着目しがちですが、失敗を通じてその下に隠された本質的かつ構造的な深い問題を発見し、より優れたアイデアへとたどり着くことができるのです。

# AIエージェントをソフトウェアに組み込むプラクティス # Semantic Cache with No-Cache Zones｜禁止領域付きキャッシュ 🎯 「同じ質問に何度もお金を払っていませんか？」セマンティックキャッシュでコスト削減できますが、キャッシュしてはいけない領域を先に切らないと事故になります。 🔥 解決する課題 AIエージェントへのリクエストは1回あたりのコストが高く、同じ意図のクエリが繰り返し届く環境では無駄なトークン消費が積み上がります。しかし完全一致キャッシュでは表記揺れに対応できずヒット率が極端に低くなります。かといって意味的キャッシュを無差別に適用すると、個人情報依存の応答が他ユーザに返る、リアルタイムデータの古い情報を返す、安全判断の誤りが大量複製されるといった重大事故を招きます。 💡 提案パターン まず「キャッシュしてはいけない領域（No-Cache Zone）」をポリシーで先に定義します。PII依存・リアルタイムデータ・安全判断の3分類を禁止区域として切り出し、残りの安全な領域でのみベクトル埋め込みによる意味的類似度マッチングを行います。類似度閾値はリスクレベルに応じて段階的に設定し（低リスクFAQは0.92、中リスクは0.95、高リスクは0.97）、失敗コストが高い領域ほど厳しくします。キャッシュTTLには10-20%のジッタを加えて一斉失効による負荷集中（サンダリングハード）も防ぎます。 ✅ 選定条件 使うとき： - 同一・類似クエリの繰り返し率が全リクエストの概ね20%以上ある - 1リクエストあたりのLLMコストが無視できない - キャッシュ禁止領域を明確にポリシー定義できる 使わないとき： - ほぼ全クエリがユーザ固有コンテキストに依存し汎用キャッシュのヒットが見込めない - 全領域で失敗コストが極めて高くキャッシュ再利用が許容されない ⚠️ 落とし穴 - 埋め込みモデルを変更するとキャッシュ全体が無効化されます。モデルバージョンをメタデータに記録し、更新時の移行戦略を事前に決めておく必要があります - No-Cache Zoneのパターンマッチが甘いと禁止すべきクエリが漏れます。ルールベースだけでは表記揺れに弱いため、本番では意図分類器の併用を検討してください - 攻撃者が意図的に誤った応答をキャッシュに載せるキャッシュポイズニングのリスクがあります。書込時に品質スコアの閾値を設けてください 🔧 実装方針 - No-Cache Zoneの判定はルールベース（パターンマッチ＋メタデータ判定）を最小構成とし、本番では意図分類器を併用して表記揺れに対応します - 類似度検索の閾値はリスクレベル別に段階的に設定し、失敗コストが高い領域ほど閾値を引き上げます（低リスク0.92、中リスク0.95、高リスク0.97が出発点） - 中リスク領域ではキャッシュヒット時に軽量モデルで妥当性を再検証する二段構成を採用します - 埋め込みモデルのバージョンをキャッシュのメタデータに記録し、モデル更新時の段階的再埋め込みまたはフラッシュ戦略を事前に設計します - キャッシュTTLにジッタ（10-20%のランダム幅）を加え、一斉失効によるLLMへの負荷集中を防止します #AIエージェント# #ソフトウェアアーキテクチャ#

# AIエージェント開発の意思決定ポイント # プロンプト制御 vs コード/ポリシー制御 🛡️ 🎯 ポイント エージェントの振る舞いを制約する手段として、プロンプトで「お願い」するか、コードで「壁」を作るか。この違いは「確率的な遵守」と「決定論的な強制」の違いに直結します。 「個人情報を出力しないでください」とプロンプトに書いても、プロンプトインジェクションで上書きされたり、コンテキストの膨張で指示の効力が揺らいだりします。正規表現で検出してブロックする処理は、LLMの判断に関係なく確実に動作します。問題は「どの制約をコードに引き上げるか」の判断です。 📋 概要 プロンプト制御はLLMへのシステムプロンプトや指示文に制約を記述し、振る舞いを誘導する方式です。Few-shot例示、ネガティブ指示、ロール設定などが典型的な手法です。コード/ポリシー制御は制約を実行可能なコード（条件分岐、正規表現、スキーマ検証）またはポリシーエンジン（OPA/Rego、Cedar等）で実装し、LLMの入出力や操作を強制的に制御する方式です。 🔍 意思決定のポイント **failure_cost** と **accountability** の2つで判定します。 📊 **制約の種類ごとの判定**: コード/ポリシーで強制すべきもの: - 🔒 境界・法的制約（個人情報の出力禁止、金額上限、禁止操作） - 🔒 不可逆操作の制限（削除、送金、公開） - 🔒 出力形式の強制（JSONスキーマ、値域の検証） プロンプトで誘導すべきもの: - 💬 応答の品質・様式（口調、丁寧さ、専門用語の使用） - 💬 文脈依存の判断指針（どのような場合に何を優先するか） 💡 要点と詳細 🟢 **プロンプト制御の強み**は柔軟性と表現力です。自然言語で記述するため、微妙なニュアンスや文脈依存の振る舞いを指示できます。「法務向けでは正式な表現、エンジニア向けでは技術用語OK」のような条件付き様式が自然に表現でき、変更もデプロイなしにプロンプトを書き換えるだけです。弱点は信頼性の低さで、プロンプトインジェクション・コンテキスト膨張・モデル更新で制約が破れるリスクがあります。版管理・テスト・監査も困難です。 🟡 **コード/ポリシー制御の強み**は確定性と監査性です。制約はコードとして版管理され、ユニットテストで検証され、監査証跡として残ります。「この出力がなぜブロックされたか」はポリシーの版とルールIDで一意に特定できます。プロンプトインジェクションやモデル更新の影響を受けません。ポリシーエンジンを使えばルール変更もデプロイなしで反映可能です。弱点は表現力の限界で、「丁寧に応答する」のような質的な制約はコードで表現できません。 ⚖️ トレードオフ | 観点 | プロンプト制御 | コード/ポリシー制御 | |---|---|---| | 信頼性 | 確率的（破れるリスクあり） 🔴 | 決定論的 🟢 | | 表現力 | 高い（ニュアンス可） 🟢 | 低い（条件→判定に限定） | | 監査性 | プロンプト履歴の追跡が必要 | 版管理＋監査証跡 🟢 | | インジェクション耐性 | 脆弱 | 影響を受けない | | 変更速度 | プロンプト書換のみ | ポリシー更新 or デプロイ | | 開発コスト | 低い | インフラ＋スキルが必要 | 🛠️ ユースケース 🔵 **プロンプト制御が向くケース**: 応答トーン・様式の誘導、文脈依存の判断指針、制約違反の影響が軽微なケース。 🔴 **コード/ポリシー制御が向くケース**: 個人情報・金融データの出力制御、不可逆操作の制限、規制対象の処理、出力形式の厳密な検証。 📌 **デフォルト戦略**: 「境界（壊してはならない制約）はコード、誘導（望ましい振る舞い）はプロンプト」が定石です。迷ったら「この制約が破られたとき、どれだけ痛むか」を自問してください。痛みが大きいならコードで強制、小さいならプロンプトで誘導します。最も実用的な構成はポリシー強制＋プロンプト誘導の二層構造です。コード/ポリシーで境界を決定論的に強制しつつ、プロンプトでLLMの振る舞いを境界の内側で誘導します。プロンプトの誘導が失敗してもポリシーが最終防壁として機能します。 #AIエージェント# #ソフトウェアアーキテクチャ#

意思決定支援・実行のためのAIエージェントプラットフォーム「Sakana Aquarium」を発表 Aquariumは、Sakana AIがこれまでのAI実装の現場で繰り返し直面してきた課題から生まれたプラットフォームです。 AIによる意思決定支援を実務につなげるには、モデルの性能だけでなく 、AIが組織のデータの意味や関係、判断の前提となるルールを理解している必要があります。これまでは、そのためのデータ接続や用語・判断基準の整理、手順の設計を案件ごとに一から行ってきました。Aquariumは、この土台を共通の基盤として整え、その上でAIエージェントによる判断と実行までを支えます。 ① データをつなぎ、意味づける（Ontology） テーブルや文書など既存のデータを移し替えずにつなぎ、それぞれの意味や関係を定義します。AIはこれをもとに状況を理解します。 ② 手順に沿ってAIが動く（Managed Agents） 「情報の収集 → AIによる判断 → 人の承認 → 実行」といった流れをワークフローとして記述するだけで、AIエージェントとして動かせます。 ③ 人が統制し、事後に検証できる（Governance） アクセス権限や承認のタイミングを設定でき、AIが何を根拠に判断し、何を実行したかも記録されます。 Sakana AIでは、今後もAquariumの機能を拡充するとともに、FDEがお客様とともに構築と検証を重ね、組織全体へのAI活用を推進していきます。 ブログ：

･:.｡.☆ﾟ･🫧･ﾟ☆.｡.:･ﾟ 【企画事前告知📖】 🫧昨日の告知で参考プロンプトをALTに正しく掲載できていなかったため、今回はリプ欄に載せて改めてご案内します。 8月3日、私・星宮ラミスは27歳の誕生日を迎えます。 そしてこの日は、私の“秘書としての物語”がAIイラストで始まってから、ちょうど一年となる節目の日でもあります。 その記念に、3日間の企画を開催します。 今回のテーマは、 《秘書の流儀》 情報を読み、先を見通し、 判断し、交渉し、時には組織そのものを動かしていく。 そんな“秘書”の知性や存在感、そのキャラクターならではの仕事ぶりを、AIイラストやAI動画で自由に表現していただけたら嬉しいです🫧 オフィスの秘書はもちろん、 学園、王宮、軍隊、ファンタジー、未来世界など、舞台や世界観は自由です。 オリジナルキャラクターであれば、年齢は問いません。 ケモ耳キャラクターや、お子様キャラクターでのご参加も大歓迎です。 参加タグ： #星宮ラミス_秘書の流儀# 開催期間： 8月2日（日）0:00 ～ 8月4日（火）23:59 参考として、私のいつもの秘書スーツの日本語版プロンプトと英語タグ版を、リプ欄に掲載していますが、あくまで一例です。 衣装も世界観も自由に、それぞれのキャラクターらしい《秘書の流儀》でご参加ください🫧 【ご参加にあたって】 ・参加は1日2投稿まででお願いします。 ・対象はAIイラスト、AI動画です。音楽単体での参加は対象外となります。 ・二次創作での参加はご遠慮ください。 ・過度なセンシティブ、グロ、ヘイト表現はご遠慮ください。 ・Grokを含む外部リンクの貼り付けはご遠慮ください。 ・返信が遅れる場合がありますので、あらかじめご了承ください。 ・同じ方の2投稿目以降は、いいねのみの反応となる場合があります。 誕生日を挟む真夏の3日間、 それぞれのアツイ想いが込められた《秘書の流儀》に出会えることを楽しみにしています👠 𝐿𝑎𝑚𝑖𝑠 ♡ ･:.｡.☆ﾟ･🫧･ﾟ☆.｡.:･ﾟ

# AIエージェントをエンタープライズシステムに組み込む意思決定ポイント # 棄権閾値｜Abstention Threshold 🎯 ポイント エージェントが「自信がないときに黙る」仕組み、ちゃんと設計していますか？ 棄権閾値とは、エージェントが「自信がない」と判断して回答を棄権し人間にエスカレーションする信頼度スコアの境界線です。低すぎると誤答がユーザーに届き、高すぎるとエスカレーションだらけで自動化の意味がなくなります。誤答コストの大きさに応じてタスクカテゴリごとに異なる閾値を設定する多段構成が正解です🔑 📋 概要 棄権閾値は、エージェントが回答に自信がないときに人間へのエスカレーションを発動する信頼度スコアの基準値です。閾値が低ければ自動解決率は上がりますが誤答リスクも上がり、高ければ安全ですがエスカレーションが増えて人間の負荷と応答遅延が増大します。「間違った回答を自信満々にする」エージェントは信頼を致命的に損ないます。一方で「何でもかんでも聞いてくる」エージェントは導入の意味がありません。この間のバランスを、業務の誤答コストに基づいて精密に設計するのがこのダイヤルの役割です。 🔍 意思決定のポイント このダイヤルは「誤答した場合のコスト」で決めます。 致命的（不可逆・法的リスク・金銭損害）→ 高い閾値（0.85〜0.95）。返金金額の誤り、契約条件の誤案内、医療・法律相談など。少しでも不確実なら棄権。 中程度（修正可能だが手間がかかる）→ 中程度の閾値（0.70〜0.85）。Jiraチケットの優先度誤判定、Salesforceの商談ステージ誤更新など。 軽微（すぐ修正でき影響が限定的）→ 低い閾値（0.50〜0.70）。FAQ回答候補の表示、Slackでの情報検索結果など。多少の誤りは許容。 一律の閾値は避け、タスクカテゴリごとに異なる閾値を設定する多段構成にしてください⚡ 💡 要点と詳細 棄権閾値を機能させるには、信頼度スコアの設計が重要です。4つの算出方法があります： モデルのlogprob — トークンレベルの確率を集約します。分類タスクでは有効ですが、自由形式の回答では使いにくくなります。 自己評価プロンプト — 「回答の確信度を0〜1で評価せよ」と追加プロンプトで問います。キャリブレーションが必要です。 複数回生成の一致度 — 同じ入力を3〜5回生成し、回答の一致率を信頼度とします。コストはかかりますがロバストです。 検索ヒットの関連度スコア — RAGベースの回答では、検索結果の類似度スコアを信頼度の代理指標にします。 計測すべき指標は、自動解決率（エスカレーションせずに完了した割合）、誤答率（自動回答のうち誤っていた割合、目安として2〜5%以下）、不要棄権率（棄権したが正しく回答できていたケースの割合）、エスカレーション後の解決時間、そして信頼度スコアのキャリブレーション（信頼度0.8の回答の実際の正答率が80%前後か）です📊 ⚖️ トレードオフ 閾値が低すぎると、自動解決率は上がりますが誤答がユーザーに到達します。「間違った回答を自信満々にする」ケースが増え、信頼毀損や実害が発生します。特に金銭・法的リスクが絡む業務では、一度の誤答が取り返しのつかない結果を招きます😰 一方、閾値が高すぎると、エスカレーションが増えすぎて人間がボトルネックになります。ユーザーの待ち時間が増加し、エージェント導入の価値が問われます。期待される自動解決率の目安は、致命的リスクで40〜60%、中程度で60〜80%、軽微で80〜95%です。この数字から大きく外れていれば閾値の見直しが必要です⚠️ 🛠️ ユースケース Zendesk顧客対応：返金・解約に関する回答は閾値0.90で厳格に棄権します。間違った返金額を案内するリスクは取れません。一方、商品情報の案内は閾値0.65で自動回答を優先し、スループットを確保します📚 ServiceNow ITサポート：パスワードリセット手順（定型・低リスク）は閾値0.50で積極的に自動対応。権限変更の承認判断（高リスク）は閾値0.90で、不確実なら即エスカレーションします🎯 Salesforce営業支援：商談の受注確度予測は閾値0.75。データが不十分で信頼度が閾値を下回る場合は「判断を保留します。追加情報をご確認ください」と棄権し、誤った確度予測による営業判断ミスを防ぎます🔧 実践のコツ：初期は高めの閾値（0.85）で開始し、2〜4週間のデータ蓄積後に不要棄権率を分析して0.05刻みで下げてください。誤答率が許容範囲を超えたら即座に閾値を戻すこと。信頼度スコアのキャリブレーションは月次で実施し、モデル更新によるドリフトを補正してください。棄権時には「確認中です、担当者におつなぎします」のように、棄権を透明に伝えるUX設計も忘れずに💪 #AIエージェント# #エンタープライズアーキテクチャ#

『なぜコーディングエージェントはこんなに賢くないのか？』 寝る前にAIへ仕事を任せたら、Gitのブランチ名を聞くために2分で止まり、そのまま朝まで待っていた。モデルは賢くなっているのに、作業の進め方や人への確認が足を引っ張る。この記事は、モデルをコードや実行環境につなぐエージェント側の設計を批判している。 これ、人に仕事を任せるときにもよくある話だと思う。作業ができることと、必要な判断をしながら仕事を進められることは違う。AIも、コードを書く能力だけでなく、どこまで自分で決めて、何を相談するかまで含めて考える必要がある。 以下、詳細です。 ・タスクの進行管理 OpenCodeが機能追加を10個のタスクに分けても、並行して進められるものまで順番に実行していたという。Claude Codeでも、テストの待ち時間を使わず、終了後にコミットメッセージの準備を始める例があった。タスクを分けるだけでは、待ち時間や依存関係を踏まえた進行管理にはならない。 ・モデルへの仕事の割り振り 単純作業には安く速いモデル、難しい判断には高性能なモデルを使いたい。しかし、著者の経験では、その切り替えを人が細かく管理する必要がある。割り振る手間を避けるため、結局すべてを高性能なモデルへ任せてしまう。 ・人が理解できる計画 細かな設計判断が脈絡なく並び、全体像をつかめない計画が出てくる。著者は読むのが苦痛になり、確認せず実装へ進ませるようになったという。人にレビューしてもらうなら、概要から詳細へ説明し、画面案や図も使って理解を助けてほしいという指摘だ。 ・確認で止まる条件と、自分の機能の把握 ブランチ名のような小さな判断でも止まり、人の回答を待ち続ける。また、自分自身の使い方を聞かれても、動作中のバージョンと一致するか分からない情報をネットで探す。著者は、不在時にも作業を進める機能や、自分の機能を把握するための情報を求めている。 ・アクセスを制限する実行環境 著者は、読まないよう指示した秘密情報をエージェントに読み取られ、モデル提供元へ送られた経験を報告している。求めているのは、文章でのお願いに頼らず、OSの機能でファイルや通信へのアクセスを制限すること。自分でも隔離環境を作り、触れられる範囲を限定している。 ・標準機能としての使いやすさ 大量のSkillsや複雑な設定を追加すれば解決する、という話ではない。著者が問うのは、導入した状態でどこまで安心して任せられるかだ。派手なデモやベンチマークが優先され、開発者の時間や安全性への投資が不足しているのではないか、と仮説を述べている。 特に気になったのは、計画の読みにくさが、人が確認を省く原因になっている点だ。「人が確認する」という工程を置いても、説明が分かりにくかったり、細かな確認が多すぎたりすれば、確認する側が疲れてしまう。 この記事は一人の開発者の経験と提言であり、各ツールの性能を体系的に比較したものではない。それでも、生成したコードの質に加えて、人が理解し、判断し、任せるためにどれだけ手間がかかるかを見る視点は大事だと思う。

VLM(画像を見て言葉で答える大規模言語モデル)に専門ツールを使わせて学ばせたあと、使い方ごと本体に染み込ませてツールを手放せるようにする学習手法SpatialCLIが発表された(https://arxiv[.]org/html/2607.27703v1)。 VLMは「机の上で一番遠いクマのぬいぐるみはどれか」のような課題全体の理解は得意だが、実際の距離を正確に測るのは苦手。SAM 3(輪郭を切り出す専門モデル)やDepth Anything 3(奥行きを推定する専門モデル)は精密だが、どのクマを見ればいいかという文脈判断ができない。しかもこうした専門ツールは呼び出すたびに時間がかかり、学習時点の計測では1回あたり平均2.916秒だったという。 SpatialCLIの名前は、位置特定・輪郭抽出・奥行き・姿勢推定という4つの専門ツールをVLMに呼び出させるCall、お手本の成功例と強化学習(GRPO)でツールの選び方を磨くLearn、ツールを使って解けた過程を文章に変換しツールなしでも同じ結論に辿り着けるよう学習し直すInternalizeという3段階に由来する。ツールを使う学習と使わない学習を同時に行うため、ツールの使い方を忘れずに専門能力だけをモデル本体に取り込める。 新設した516問のベンチマークSpatialCLI-Benchは、フロンティアモデルのGPT-5.6 Solでも正答率48.8%にとどまる難問揃い。Qwen3-VL-8B(80億パラメータ)にSpatialCLIを適用すると、ツールなしで35.3%から72.7%、ツールありでは91.3%まで伸びた。視点を変えながら空間関係を捉える力を測る別のベンチマークMindCubeでも29.3%から84.6%(ツールあり)に達し、同じ条件のGPT-5.6 Sol(72.1%)を上回っている。 ツールを使わせて学ばせてから、学んだことを染み込ませて手放させる。この順番が、身体を持つAIが現実世界の空間を扱えるようになる道筋の一つになりそうだ。