スマートコントラクト（ブロックチェーン上で自動実行される契約プログラム）に AI エージェントを組み合わせる設計を検討しているエンジニアに向けて、実装例をもとに役割分担の考え方を整理します。
題材はナイジェリアの伝統的な頼母子講（たのもしこう）「Ajo（アジョ）」を Solana 上のプログラムと Gemini エージェントで再現した個人プロジェクトです。Ajo は5人が定額を出し合い、毎回1人が総取りする輪番型の貯蓄組合で、日本の「講」や「無尽」と同じ仕組みです。このプロジェクトが興味深いのは、AI にどこまで判断を任せ、どこから人間とコード側に権限を残すか、という線引きが明快な点にあります。
何が作られたのか
Ajo Chain と名付けられたこのプロジェクトは、5人組の輪番貯蓄を Solana の on-chain プログラム（ブロックチェーン上に直接デプロイされる実行コード）で管理します。従来の Ajo は「壺（pot）」と呼ばれる集金役を1人の人間が担い、その人の信用だけが担保でした。要約にあった通り、集金役が家庭の事情で立て替えたお金を返せなくなり、グループ全体が損失を被った実例が動機になっています。
この設計では、エスクロー（第三者が資金を一時的に預かる仕組み）、支払い順序、延滞記録のすべてを Solana プログラムの PDA（Program Derived Address、プログラムが管理する専用アカウント）上に置きます。人間の集金役を排除し、コードが資金移動の唯一の実行者になる構造です。
段階的に見る技術的な仕組み
プログラムは4つの命令（instruction）で構成されています。
create_group: グループ作成と輪番順の固定contribute: 各メンバーの拠出mark_default: 延滞の記録release_payout: 全員拠出後の支払い実行
release_payout の中身が設計の核心です。公開されたコードでは、支払い前に2つの require! マクロ（Anchor フレームワークの条件検証機構）でチェックを行っています。1つは全メンバーの拠出完了確認、もう1つは受取人アドレスが輪番配列の現在の順番と一致するかの確認です。
重要なのは、受取人アドレスを呼び出し側が指定できる余地を残していない点です。アドレスはグループの on-chain 状態から直接読み出され、外部から渡されるパラメータには依存しません。これにより「本来受け取るべきでない人に送金される」という攻撃経路を構造的に塞いでいます。
テストには litesvm（Solana 用の軽量インプロセス実行環境）を採用し、ローカルバリデータやフォーセット（テスト用トークン配布）を使わずに3種のテストを実行しています。ハッピーパス、意図的な延滞後の遅延キャッチアップ、非メンバーや二重拠出の拒否、という3パターンです。
AI エージェントはどこに置かれているか
ここからが AI 駆動開発の観点で注目すべき部分です。スマートコントラクトは「拠出が届かなかった」という事実は検知できますが、「なぜ届かなかったか」までは判断できません。送金失敗なのか、支払う意思がそもそも見えないのか、コードには区別がつきません。
この空白を埋めるために、Gemini（Google の生成 AI モデル）を使った1つの狭い役割のエージェントが追加されています。役割は「on-chain の証拠を読み、人間のモデレーター向けに平易な言葉でメモを起草すること」のみです。
このエージェントの権限設計には明確な制約があります。
- エージェントは事実を確定させない。起草するだけで最終判断は人間が行う
- 対象は devnet（Solana のテスト用ネットワーク）のみで、実資金は扱わない
- 判断対象は「送金が on-chain で失敗した」か「支払おうとした形跡が見えない」かの区別に限定
この設計思想は、AI コーディングツールを実運用に組み込む際の基本原則と重なります。MCP（Model Context Protocol、AI エージェントが外部ツールやデータソースと連携する標準規格）を使ったエージェント連携でも、書き込み権限や実行権限を AI に直接持たせるか、人間承認を挟むかは設計の分岐点になります。ここでは「金銭移動の実行」はコード側に閉じ、「曖昧な状況の言語化」だけを AI に渡すという分離が徹底されています。
既存の実装パターンとの比較
スマートコントラクトと AI を組み合わせる設計にはいくつかの類型があります。
| パターン | AI の役割 | リスク |
|---|---|---|
| AI が直接トランザクション実行 | 判断も実行も担う | 誤判断がそのまま資金移動に直結 |
| AI がオラクル的に外部情報を提供 | 価格や事象の証明を提供 | 入力データの信頼性に依存 |
| 今回の方式(起草のみ) | 人間向けの説明文生成のみ | 最終判断は人間、実行はコード |
Ajo Chain が採用したのは3つ目のパターンです。AI エージェントの出力が誤っていても、資金が誤送金される経路には直結しません。これは「AI の出力は信頼できないことがある」という前提に立った、防御的な設計と言えます。
今日確認できること
自分のプロジェクトで似た構成を検討する場合、確認しておきたいポイントを挙げます。
- 資金や状態変更を伴う処理で、AI の出力が直接実行系に渡っていないか。渡っている場合は人間承認のステップを挟めないか検討する
- Solana プログラムを書く場合、
require!などの検証ロジックが「送金処理の前」に置かれているか。後置きチェックは競合状態のリスクが残る - テストに
litesvmのようなインプロセス実行環境を使うと、ローカルバリデータ起動のオーバーヘッドなしに CI に組み込みやすくなる。GitHub Actions 等での高速なテスト実行を検討している場合は候補になる - AI エージェントに渡す範囲を「読み取りと説明文生成のみ」に絞れないか。MCP 経由でツール連携する構成でも、書き込み系ツールと読み取り系ツールを明確に分離する設計は流用できる
公開されているコードは GitHub 上で確認可能で、Program ID（Solana 上のプログラム識別子）も公開されています。実際の require! マクロの並び順や、release_payout 命令のアカウント制約（Anchor の #[derive(Accounts)] 部分）を読むと、権限分離の実装パターンがそのまま読み取れます。同様の設計を検討する際は、まずこの部分を写経してみるのが理解の近道です。
まとめ
Ajo Chain の設計から読み取れるのは、AI エージェントに「判断の一部」だけを渡し、「実行の権限」はコード側に残すという分離の徹底です。
- 資金移動などの重い実行はスマートコントラクト側の検証ロジックに閉じ込める
- AI エージェントは曖昧な状況の言語化・起草に役割を限定する
- devnet のようなテスト環境で先に権限設計を検証してから本番導入を検討する
自分のプロジェクトで AI エージェントと自動化処理を組み合わせる際は、まず「AI の出力が誤っていた場合、最悪どこまで被害が広がるか」を書き出してみると、権限をどこで区切るべきかの判断材料になります。