Use Cases

ICP には入口が2つあります。このサイト自体がその両方を持っています。

前者は普通のWebと同じなのでAIも読めます。面倒なのは後者だけで、これには4段階が必要でした。① キャニスターIDを知る ② Candid（インターフェース定義）を読む ③ 引数を Candid 形式に変換する ④ 署名する identity を用意して呼ぶ。

Web2なら「URLを叩けばJSONが返る」で済む話が、ICPでは4段階。人間でも面倒で、AIには事実上無理でした。

ICPには「APIキー」という概念がそもそもありません。 ここが他サービスとの決定的な差です。

Web2のAPIキーは sk-proj-xxxxx… のような文字列で、意味はひとつ「これを持っている人＝本人」。だから渡すことは本人になれる権利を丸ごと渡すことで、コピーされても見分けがつかず、取り消すには作り直して全部差し替えるしかない。比喩は合鍵です。

ICPでは、キャニスターへの呼び出しはすべて秘密鍵で署名されています。「文字列を持っているか」ではなく「署名できるか」で本人確認する。共有する秘密が存在しません。

ではAIに秘密鍵を渡すのか。渡しません。 ここで delegation（委任状）が出てきます。

1. AIアプリ側が、その場限りの鍵ペア（セッション鍵）を作る
2. あなたの Internet Identity がその公開鍵に署名を出す。内容は「この鍵の持ち主は、◯月◯日◯時まで、この宛先において私の代理をしてよい」
3. AIはこの署名済みの紙と、自分のセッション鍵で署名して呼び出す
4. キャニスター側が「署名はIIのものか」「期限内か」「宛先は合っているか」を検証して受け入れる

比喩は合鍵ではなく期限付きの委任状。あなたの実印（秘密鍵）は手元から動かず、委任状には期限と相手先が書いてあり、期限が来れば自動で無効。途中で取り消しもできます。

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が何かを壊すことは構造的にありえない」が成立します。

26ツールの内訳

案内ページ ↗ 公式ドキュメント ↗

問題は 「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つは動かないだけでなく壊れる類のミスです。

規模は 27スキル / 10カテゴリ / Apache 2.0（2026-08-09時点）。とりあえず試すなら準備ゼロの On-demand、チーム開発やCIで再現性が要るなら npx skills add で固定する Pinned を使い分けます。

skills.internetcomputer.org ↗

なぜこれが「AI時代」の設計なのか

• YAML + recipe ＝ 宣言的。AIが壊しにくい
• 環境の抽象化 ＝ AIがうっかり本番を叩く事故が減る
• プロジェクトローカルなネットワーク ＝ AIを並列で走らせても干渉しない
• llms.txt ＝ ドキュメント全体をAIにURL1本で渡せる

dfx からの移行手順 ↗

キャニスターは WASM で動き、全ノードが同じ結果を出す（決定的実行）必要があり、命令数にも上限があります。一方 Llama 3.1 8B は数GB。サブネットの合意の中で毎回回すのは素直には無理です。

だからDFINITYの解は「キャニスターの外に専用ノードを置き、キャニスターはそこへの窓口になる」。これが AI workers と LLM canister です。開発者から見えるのは await LLM.prompt(#Llama3_1_8B, "光の速さは？") の1行だけ。

一方で、小さいモデルなら本当にキャニスター内で動くことを示すプロジェクトもあります（onicai が32bitキャニスターに DeepSeek 1.5B、DecideAI が GPT-2）。発信するときは実用寄り（中継あり）と研究寄り（小型・完全オンチェーン）を分けて書くと、正確かつ話が面白くなります。