道具は3つ。MCP・Skills・CLI
AIエージェントがICP上でアプリを作り、動かし、運用するための道具立てが2026年に出揃いました。ICP MCP がAIとICPをつなぎ、ICP Skills がAIに正しい書き方を教え、ICP CLI がAIの壊しにくい足場になります。このページは、その3つを非エンジニアでも分かる順序で説明します。
3つの道具は、それぞれ別の問題を解いている
混同されがちですが、役割はきれいに分かれています。順に見ていけば、どれをいつ使うのか迷いません。
ICP MCP
AIとICPをつなぐ。 AIチャットからキャニスターを探し、質問し、必要なら操作する。DFINITY公式のコネクタで、認証は Internet Identity。
ICP Skills
AIに正しい書き方を教える。 AIは古い知識で自信満々に間違えます。「こう書け」「ここで落ちる」を宛先AIで書いた公式ナレッジ。
ICP CLI
AIが壊しにくい足場をつくる。 dfx の後継。宣言的な設定と環境の抽象化で、AIがうっかり本番を叩く事故を減らします。
なぜ ICP のアプリは、これまで AI から操作できなかったのか
ICP には入口が2つあります。このサイト自体がその両方を持っています。
| 入口 | 何をするか | 例 |
|---|---|---|
| HTTPで見る | ブラウザがキャニスターから HTML を受け取る | www.icp-japan.org を開く |
| メソッドを呼ぶ | アプリのロジックを実行する | 残高を取る、投票する、データを書く |
前者は普通のWebと同じなのでAIも読めます。面倒なのは後者だけで、これには4段階が必要でした。① キャニスターIDを知る ② Candid（インターフェース定義）を読む ③ 引数を Candid 形式に変換する ④ 署名する identity を用意して呼ぶ。
Web2なら「URLを叩けばJSONが返る」で済む話が、ICPでは4段階。人間でも面倒で、AIには事実上無理でした。
APIキーではなく「期限付きの委任状」
ここが他サービスとの決定的な差です。ICPには「APIキー」という概念がそもそもありません。
Web2のAPIキーは sk-proj-xxxxx… のような文字列で、意味はひとつ「これを持っている人＝本人」。だから渡すことは本人になれる権利を丸ごと渡すことで、コピーされても見分けがつかず、取り消すには作り直して全部差し替えるしかない。比喩は合鍵です。
ICPでは、キャニスターへの呼び出しはすべて秘密鍵で署名されています。「文字列を持っているか」ではなく「署名できるか」で本人確認する。共有する秘密が存在しません。
ではAIに秘密鍵を渡すのか。渡しません。 ここで delegation（委任状）が出てきます。
- AIアプリ側が、その場限りの鍵ペア（セッション鍵）を作る
- あなたの Internet Identity がその公開鍵に署名を出す。内容は「この鍵の持ち主は、◯月◯日◯時まで、私の代理をしてよい」
- AIはこの署名済みの紙と、自分のセッション鍵で署名して呼び出す
- キャニスター側が「署名はIIのものか」「期限内か」を検証して受け入れる
比喩は合鍵ではなく期限付きの委任状。あなたの実印（秘密鍵）は手元から動かず、期限が来れば自動で無効になり、途中で取り消すこともできます。仕様上の上限は30日、既定は30分で、アプリが maxTimeToLive で希望を伝えます。
もうひとつ効いているのが、あなたのIDがフロントエンドのホスト名ごとに別々に導出されることです。II仕様の言葉では「ユーザーはクライアントアプリごとに別の識別子を持ち、それらは公開鍵やprincipalだけを見ても関連づけられない」。つまりAIに使わせても、アプリをまたいで名寄せされません。
そしてICPはこのために新しいものを何も作っていません。Internet Identity は2021年からこの仕組みで、ICP MCP はそれをそのまま使っただけ。逆にWeb2のMCPサーバー（Slack / Notion / GitHub…）がAPIキーやOAuthトークンを渡さざるを得ないのは、Web2側にこの仕組みが無いからです。
AI時代に必要になった「期限付きで、取り消せる代理権」を、ICPは5年前から持っていた。
「読むだけモード」が本当に安全な理由
ICPのサブネットは13台や34台のノードで構成され、その全部が同じキャニスターのコピーと同じデータを持っています。
データを書き換えるときは、全ノードが同じように書き換わらないと困ります（1台だけ残高が違ったら、どれが正しいか分からない）。だから書き換えは全ノードで合意を取る。これが update call で、遅い（1〜2秒）代わりに改ざんできません。
読むだけのときは合意が要りません。1台に聞けば答えは返るし、書き換わらないのでズレる心配もない。これが query call で、速く（数百ms）、状態は一切変わりません。
肝心なのは、どちらかをコードを書くときに宣言すること。Motoko なら public query func … と書くかどうか。そして query と宣言したメソッドは状態を書き換えられません。書こうとしてもコンパイラとランタイムに弾かれる。実装者が気をつけているのではなく、そもそも書けないのです。
だから ICP MCP の Questions-only モードがやっているのは、実質これだけ — AIには query call しか通さない。これで「AIが何かを壊すことは構造的にありえない」が成立します。
| 何が保証しているか | 破れるか | |
|---|---|---|
| Web2の「読み取り専用APIキー」 | サーバー側の実装。「このキーはGETだけ」と誰かが書いた | 破れる（実装ミス・設定ミス・スコープの取り違え） |
| ICPの query call | プロトコル。読み取り用の通り道が別 | 破れない（アプリの実装品質に依存しない） |
ただし裏返しの注意もあります。query の応答はサブネットの署名が付いていないため、公式ドキュメントは「certified variables を使わないかぎり、queryの結果は未検証として扱うこと」と明記しています。速さと引き換えに何を受け入れているのかは、知っておく価値があります。
ICP MCP — AIチャットからICPを操作する
DFINITY公式の、AIチャットとICPをつなぐコネクタ。ICP上にホストされています。
| エンドポイント | https://mcp.internetcomputer.org/mcp |
|---|---|
| 公開 | 2026-07-23 プレビュー（beta） |
| 対応クライアント | Claude / ChatGPT など MCP対応アプリにカスタムコネクタとして追加 |
| 認証 | Internet Identity でサインイン |
| セッション | 1時間 / 24時間 / 7日、いつでも revoke |
| モード | Actions and questions（実行あり）/ Questions-only（参照のみ） |
26ツールの内訳（5グループ）
| グループ | 数 | できること |
|---|---|---|
| Find canisters and apps | 6 | ドメイン・名前・IDのどれからでも「それが何で、誰が制御し、どう振る舞うか」をAIが読める形に |
| Act as your identity | 3 | AIがアプリ上であなたのIIとして振る舞う。委任はオンデマンド発行 |
| Query on-network data | 3 | クエリ面を公開しているキャニスターに質問すると表で返る。コード不要 |
| Call methods and manage canisters | 12 | cycles残高確認からフルデプロイまで。キャニスター作成・top up・コードインストール・ライフサイクル管理 |
| Pull in official IC skills | 2 | 作り始める前に公式スキル（Motoko / mops / CLI / cycles / セキュリティ）を取得 |
出典: ICP MCP 案内ページ（DFINITY公式・beta）↗ AIコーディングエージェント向けドキュメント ↗
ICP Skills — 「宛先が人間ではなくAI」のドキュメント
問題は 「AIは知らないと言わず、それらしく間違える」 ことです。
たとえば Motoko の標準ライブラリは mo:base から mo:core に変わりました。しかしAIの学習データには mo:base 時代のコードが圧倒的に多い。だから「Motokoで書いて」と頼むと、AIは自信満々に import Array "mo:base/Array"; と書きます。動きません。エラーを見せると、今度は別の間違った修正を出す。3往復して、結局自分で調べることになる。しかもAIが悪いわけではありません — 学習した時点ではそれが正解でした。
同じことがICPのあちこちで起きます。dfx.json と icp.yaml、ステーブルメモリの書き方（間違えるとアップグレードでデータが消える）、ICRC-1とICRC-2の使い分け、cycles の freezing threshold（間違えるとキャニスターが凍る）。後ろ2つは動かないだけでなく壊れる類のミスです。
| ドキュメント | Skill | |
|---|---|---|
| 読む相手 | 人間 | AI |
| 書いてあること | 文脈、背景、選択肢の比較 | 「こう書け」「これはやるな」「ここで落ちる」 |
規模は 27スキル / 10カテゴリ / Apache 2.0（2026-08-09時点）。とりあえず試すなら準備ゼロの On-demand、チーム開発やCIで再現性が要るなら npx skills add で固定する Pinned を使い分けます。
出典: ICP Skills（DFINITY公式）↗ スキル一覧（index.json）↗ Motoko ドキュメント ↗
ICP CLI — dfx の後継。なぜ「AI時代の設計」なのか
設定の書き方とデプロイ先の指定が変わりました。違いは小さく見えて、AIに任せるときに効いてきます。
| dfx | icp-cli | |
|---|---|---|
| 設定 | dfx.json（JSON） | icp.yaml（YAML） |
| デプロイ先 | --network ic でネットワーク直指定 | 環境の抽象：-e ic |
| ビルド | dfxがロジックを内蔵 | recipe に委譲 |
| ローカルネット | 全プロジェクト共有 | プロジェクトごとに独立 |
| 並列 | 依存関係を明示 | 既定で並列ビルド |
なぜこれが「AI時代」の設計なのか
- YAML + recipe ＝ 宣言的。AIが壊しにくい
- 環境の抽象化 ＝ AIがうっかり本番を叩く事故が減る
- プロジェクトローカルなネットワーク ＝ AIを並列で走らせても干渉しない
llms.txt＝ ドキュメント全体をAIにURL1本で渡せる
オンチェーンAIの現在地 — 盛らないための注意
「ICPの上でAIが動く」という言い方は、正確には二種類あります。混ぜて語ると嘘になります。
キャニスターは WASM で動き、全ノードが同じ結果を出す（決定的実行）必要があり、命令数にも上限があります。一方 Llama 3.1 8B は数GB。サブネットの合意の中で毎回回すのは素直には無理です。
だからDFINITYの解は「キャニスターの外に専用ノードを置き、キャニスターはそこへの窓口になる」。これが AI workers と LLM canister です。開発者から見えるのは await LLM.prompt(#Llama3_1_8B, "光の速さは？") の1行だけ。
dfinity/llm のREADMEでこう書いています — 「Internet Computer 全体としてまだ機密性を保証しておらず、AI worker についても同じ。AI worker を動かしている者は理屈の上ではプロンプトを見得るが、誰が投げたかは特定できない」。DFINITY は「プロンプトそのものは記録せず、リクエスト数やトークン数などの集計値のみ記録する」とも明記しています。ここを盛ると嘘になります。
一方で公式ドキュメントは、推論がICPのランダムビーコンから種を得ており、実行ラウンドごとに決定的でサブネットが検証できるとも書いています。「外部APIを叩いているだけ」でもありません。機密性は無いが、検証可能性はある——この線引きが現在地です。
また、小さいモデルなら本当にキャニスター内で動くことを示すプロジェクトもあります。onicai の llama_cpp_canister は llama.cpp をキャニスターに載せ、DeepSeek-R1 1.5B までを動かしています。発信するときは実用寄り（LLM canister 経由）と研究寄り（小型・キャニスター内実行）を分けて書くと、正確かつ話が面白くなります。
出典: AI inference（ICP公式ドキュメント）↗ dfinity/llm README ↗ onicai/llama_cpp_canister ↗
今日から始める3ステップ
いきなり作り始めなくて構いません。順番に踏めば、リスクをほぼゼロにしたまま感触がつかめます。
1. 読むだけで繋ぐ
ICP MCP をAIチャットに追加し、Questions-only ＋ 1時間で接続。キャニスターは1バイトも変わりません。まず「このドメインは何のキャニスターか」と聞いてみるところから。
2. スキルを読ませる
コードを書かせる前に ICP Skills を取得させる。準備ゼロの On-demand でよく、これだけで古い書き方による手戻りが激減します。
3. 小さく作る
新規プロジェクトから ICP CLI を試す。既存の本番を急いで移す必要はありません。壊れて困らないものから始めるのが定石です。
情報源
このページの記述は、以下の一次情報にあたって書いています。参照日は 2026年8月9日。
| 内容 | 出典 |
|---|---|
| query call / update call の違い、queryが未検証である点 | Canisters — Query calls ↗ |
| アプリごとに別のprincipalが導出される、委任の期限（最大30日・既定30分）、委任がunscopedであること | Internet Identity 仕様 ↗ |
| Candid によるインターフェースの自己記述 | Candid ↗ / Candid 仕様 ↗ |
| ICP MCP のツール数・グループ・セッション・モード（beta） | ICP MCP 案内ページ ↗ |
| ICP Skills のスキル数・カテゴリ・ライセンス | ICP Skills ↗ / index.json ↗ |
| ICP CLI の設計と dfx からの移行 | ICP CLI ドキュメント ↗ |
| Motoko の標準ライブラリ（mo:base → mo:core） | Motoko ドキュメント ↗ |
| LLM canister / AI workers、機密性の限界、対応モデル | AI inference ↗ / dfinity/llm ↗ |
| キャニスター内で動く小型LLM（DeepSeek-R1 1.5B） | onicai/llama_cpp_canister ↗ |