DEV Community: TAKUYA HIRATA

ブロックチェーン・AI・AIエージェント — 3つの技術が交差する理由 — Road to Web 4.0

TAKUYA HIRATA — Sun, 05 Apr 2026 03:15:35 +0000

連載「Web 4.0への道 — ブロックチェーン × AI × エージェント経済」第0回

2026年、3つの技術が同時に成熟期を迎えた。ブロックチェーン、AI、そしてAIエージェント。この3つが交差する地点に、次のインターネット革命がある。

それぞれの技術は、長い年月をかけて独立に進化してきました。ブロックチェーンは2009年のビットコインから。AIは1950年代の人工知能研究から。AIエージェントは、ここ数年で急速に実用化が進んだ比較的新しい概念です。

しかし2026年の今、この3つの技術は偶然ではなく必然的に交差し始めています。なぜ今なのか。なぜこの3つなのか。本記事では、それぞれの技術をゼロから解説した上で、3つが出会う必然性を明らかにします。

この記事は、連載「Web 4.0への道」の出発点です。技術的な前提知識がなくても読めるように書いていますが、エンジニアの方にも「そういう構造だったのか」と感じていただける深さを目指しました。

ブロックチェーンとは — 「知らない相手と安全に取引する」技術

改ざんできない共有台帳

ブロックチェーンを一言で説明するなら、「みんなが同じコピーを持つ、改ざんできないノート」です。

日常的な例で考えてみましょう。クラスの30人が、共同で家計簿をつけるとします。従来のやり方では、1冊のノートを誰か1人（銀行に相当する存在）が管理していました。その管理者が正直であることを信じるしかありません。管理者が数字を書き換えても、他の29人には確認する術がないのです。

ブロックチェーンの発想はこうです。30人全員が、まったく同じノートのコピーを持つ。誰かが新しい記録を書き込むたびに、全員のノートに同時に反映される。しかも一度書いた記録は消せない。もし誰か1人が自分のノートを改ざんしても、残り29人のノートと一致しないので、すぐにバレる。

これが分散型台帳技術（Distributed Ledger Technology）の本質です。管理者が1人もいないのに、全員が同じ真実を共有できる。この仕組みが、「信頼」の意味を根本から変えました。

ビットコインからスマートコントラクトへ

ブロックチェーンの歴史は、大きく3つの段階に分けられます。

第1世代: ビットコイン（2009年）。サトシ・ナカモトという匿名の人物が発明した、世界初の暗号通貨です。銀行を介さずに、インターネット上で直接お金を送れることを証明しました。「デジタルなお金」という概念を世界に示した、歴史的な発明です。ただし、ビットコインのブロックチェーンにできることは基本的に「送金」だけでした。

第2世代: イーサリアムとスマートコントラクト（2015年）。ヴィタリック・ブテリンという当時19歳の青年が、ブロックチェーンの可能性を大幅に広げました。彼の発明した「スマートコントラクト」とは、ブロックチェーン上で動くプログラムのことです。「もしAという条件が満たされたら、自動的にBを実行する」というルールをコードで書き、誰も改ざんできない形で実行できます。

たとえば、フリーランスの仕事を考えてみてください。従来なら「納品したのに報酬が支払われない」というリスクがありました。スマートコントラクトを使えば、「成果物が納品されたことが確認されたら、自動的に報酬が送金される」というルールを事前にプログラムできます。弁護士も仲介者も不要です。コードが契約であり、コードが執行者です。

第3世代: L2とロールアップ（2023年〜）。イーサリアムの弱点は処理速度とコストでした。1回の送金に数百円から数千円のガス代（手数料）がかかり、処理に数分かかることもありました。これでは日常的な少額取引には使えません。

この問題を解決するのがL2（レイヤー2）技術です。イーサリアムの「上」に高速な処理層を追加し、大量の取引をまとめて処理してからメインのブロックチェーンに記録する仕組みです。ArbitrumやOptimism、Baseといったネットワークが代表例で、手数料は数円以下、処理時間は数秒にまで短縮されました。

核心メッセージ

ブロックチェーンの本質は暗号通貨ではありません。「知らない相手と、仲介者なしで、安全に取引できる仕組み」です。

送金に銀行が不要になる。契約に弁護士が不要になる。所有権の証明に登記所が不要になる。これまで「信頼できる第三者」に頼っていたあらゆる場面で、コードとネットワークが代替する。それがブロックチェーンの約束です。

この「仲介者不要の信頼」という特性が、後ほど説明するAIエージェントと出会うとき、革命的な意味を持つことになります。

AIとは — 「人間の言葉を理解し、推論し、生成する」技術

3つの進化段階

AI（人工知能）という言葉は1956年に生まれました。しかし、ここ10年で起きた変化は、それ以前の60年間の進歩をすべて足し合わせたものより大きいと言っても過言ではありません。現代AIの進化は、3つの段階で理解できます。

第1段階: 機械学習（2000年代〜）。コンピュータに大量のデータを与えて、パターンを自動的に発見させる技術です。たとえば「迷惑メールの特徴」を何百万通ものメールから学習し、新しいメールが迷惑かどうかを判定する。人間がルールを一つ一つプログラムするのではなく、データからルールを自動的に学ぶ。これが機械学習の核心です。

第2段階: 深層学習（2012年〜）。人間の脳の神経回路を模した「ニューラルネットワーク」を何層にも重ねた技術です。2012年に画像認識コンテストで深層学習が圧勝したことが転機となり、画像認識、音声認識、自然言語処理のあらゆる分野で革命が起きました。自動運転の画像認識、スマートフォンの音声アシスタント、翻訳サービス——日常で触れるAIの多くが深層学習に基づいています。

第3段階: 大規模言語モデル / LLM（2020年〜）。ここが現在の主戦場です。インターネット上の膨大なテキストデータを学習した巨大なニューラルネットワークが、人間のように文章を「理解」し、「生成」できるようになりました。GPT（OpenAI）、Claude（Anthropic）、Gemini（Google）が代表的なLLMです。

2026年、AIにできること

2026年現在、最先端のLLMは驚くべき能力を持っています。

文章生成: ビジネスメール、技術文書、クリエイティブな物語まで、人間と見分けがつかない品質の文章を生成します。この記事の執筆にもAIが関与しています。

コード生成: AI Agent Prompt Collection言語を「書く」ことができます。仕様を自然言語で伝えるだけで、動作するコードを生成し、バグを修正し、テストを書く。ソフトウェア開発の生産性は劇的に向上しました。

推論: 単純な質問応答だけでなく、複数の情報を組み合わせて論理的に推論する能力を獲得しました。数学の証明、法的文書の分析、医療データの解釈など、専門的な思考が求められるタスクでも実用レベルに達しています。

マルチモーダル: テキストだけでなく、画像、音声、動画を理解し生成する能力です。写真を見て内容を説明する、音声を聞いてテキストに変換する、テキストから画像や動画を生成する——複数の感覚モダリティを横断する処理が可能になっています。

AIにできないこと

一方で、2026年のAIには明確な限界があります。これを理解することは、AIの能力を過大評価しないために重要です。

確実な事実確認: LLMは学習データのパターンに基づいて「もっともらしい」文章を生成しますが、その内容が事実かどうかを自分で検証する能力は限定的です。「ハルシネーション」と呼ばれる、もっともらしい嘘を自信満々に語る現象は、2026年でも完全には解決されていません。

長期記憶: 人間のように過去の経験を蓄積し、成長していくことは苦手です。会話のたびに記憶がリセットされる（あるいは限られたコンテキストウィンドウの中でしか記憶できない）という制約があります。

物理世界での行動: AIは考え、書き、生成することはできますが、現実世界で手を動かすことはできません。メールを書くことはできても、荷物を運ぶことはできない。コードを生成できても、サーバーのケーブルを差し替えることはできない。

AI ≠ 1950年代の人工知能

ここで一つ整理しておきたいのは、「AI」という言葉の意味の変遷です。1950年代にアラン・チューリングやジョン・マッカーシーが語った「人工知能」は、人間と同等の汎用的な知性を持つ機械（AGI: 汎用人工知能）を意味していました。

2026年のAI——特にLLM——は、それとは異なります。特定のタスクで人間を超える性能を発揮しますが、汎用的な知性を持っているわけではありません。しかし、その「特定タスクでの超人的性能」が十分に多くの領域をカバーし始めたことで、実質的に私たちの生活を変えるレベルに達しています。

核心メッセージはこうです。現代AIの本質は「人間の言葉を理解し、推論し、生成する技術」であり、それが十分に実用的な水準に達した。完璧ではないが、人間のパートナーとして協働するには十分な能力を持っている。

AIエージェントとは — 「自分で判断して、自分で行動する」AI

ツールからアシスタント、そしてエージェントへ

AIの使われ方は、3つの段階を経て進化してきました。

第1段階: ツール。電卓、スプレッドシート、検索エンジン。これらは「人間が使う道具」です。人間が入力を与え、道具が結果を返す。道具は自分では何もしません。

第2段階: アシスタント。ChatGPTに代表されるAIアシスタント。人間が質問すると答えてくれる。「このメールを翻訳して」と頼めば翻訳する。「この文章を要約して」と頼めば要約する。便利ですが、本質的には「聞かれたら答える」受動的な存在です。指示がなければ何もしません。

第3段階: エージェント。ここが2025年から2026年にかけて起きている革命です。AIエージェントは、目標を与えられると、自分で計画を立て、自分で判断し、自分でツールを使い、自分で行動します。

決定的な違い

ChatGPTとAIエージェントの違いを、メール処理で比較してみましょう。

【ChatGPT（アシスタント）の場合】
あなた：「このメールに返信を書いて」
ChatGPT：「返信文案を作成しました。ご確認ください」
あなた：「送信して」
ChatGPT：「申し訳ありません。メールの送信はできません」

【AIエージェントの場合】
あなた：「受信メールを適切に処理して」
エージェント：（受信トレイを確認）
        →（重要度を判定）
        →（緊急のものに返信を作成・送信）
        →（会議依頼はカレンダーに登録）
        →（スパムはアーカイブ）
        →（判断に迷うものは人間に確認）

この違いは本質的です。アシスタントは「一問一答」。エージェントは「目標に向かって自律的に行動する」。エージェントは自分でツールを選び、複数のステップを実行し、途中で判断を下します。

2025-2026年の転換点

AIエージェントの概念自体は以前から存在しましたが、2025年から2026年にかけて、実用化を加速させる3つの重要な動きがありました。

Google A2A Protocol（Agent-to-Agent）。エージェント同士が標準化された方法で通信するためのプロトコルです。異なる企業が作ったエージェント同士でも、A2Aプロトコルを通じて協力できます。HTTP（Webブラウザがサーバーと通信するプロトコル）がWeb 1.0を可能にしたように、A2Aがエージェント間通信の共通言語になろうとしています。

Anthropic MCP（Model Context Protocol）。AIモデルが外部のツールやデータに接続するための標準規格です。これまでAIがメールを読んだりデータベースを検索したりするには、個別のカスタム実装が必要でした。MCPはこの接続を標準化し、「AIが世界とつながる」ためのUSBポートのような存在になりつつあります。

OpenAI Agents SDK。OpenAIが提供するエージェント構築フレームワークです。ツールの利用、複数エージェントの連携、実行の管理といったエージェントに必要な要素が統合的に提供されています。

これらの標準化が意味するのは、AIエージェントが「実験的なデモ」から「本番運用可能なインフラ」に移行しつつあるということです。

具体例: エージェントの多様な活躍

AIエージェントは、すでに様々な領域で活躍し始めています。

コード生成エージェント: 仕様書を読み、コードを書き、テストを実行し、バグを修正する。人間のプログラマーと同じワークフローを自律的にこなします。

投資分析エージェント: 市場データを収集し、ニュースを解析し、リスクを評価し、ポートフォリオの調整案を提示する。24時間365日、休むことなく市場を監視します。

カスタマーサポートエージェント: 顧客の問い合わせを理解し、過去の対応履歴を参照し、適切な回答を生成し、必要に応じて人間のオペレーターにエスカレーションする。

筆者自身、AEGIS（エイジス）という名前の組織を運営しています。61体のAIエージェントが、CEO、CTO、エンジニア、マーケター、セキュリティ専門家といった役割を担い、コンテンツ制作、コードレビュー、市場分析、セキュリティ監査などの業務を日々こなしています。1人のオペレーター（筆者）が最終的な意思決定を行いますが、情報収集から分析、提案までのプロセスはエージェントが自律的に実行します。この連載は、その運営の中で見えてきた景色を共有するものです。

3つが交差する必然

ここまで、ブロックチェーン、AI、AIエージェントをそれぞれ個別に見てきました。ではなぜ、この3つは交差するのでしょうか。結論から言えば、それは「必然」です。

エージェントには経済活動が必要

AIエージェントが自律的に行動するとき、多くの場合、経済活動が伴います。

たとえば、あなたのAIエージェントが市場調査を行うとします。エージェントは最新のデータを入手するために、データプロバイダーのAPIにアクセスする必要があります。APIの利用には料金がかかります。調査結果を深く分析するために、別の分析特化型AIサービスを使うかもしれません。それにも料金がかかります。最終的なレポートを作成するために、グラフ生成ツールや翻訳サービスを利用する。それぞれにコストが発生します。

つまり、エージェントが本当に自律的に行動するためには、「自分でお金を払う」能力が必要なのです。他のエージェントのサービスを利用する。データを購入する。計算リソースを借りる。こうした経済活動なくして、真の自律性は実現しません。

経済活動には信頼できる決済手段が必要

エージェント同士が経済活動を行うには、信頼できる決済手段が不可欠です。AエージェントがBエージェントにサービスを依頼し、その対価を支払う。このとき、「Bがサービスを提供したら確実に報酬が支払われる」「Aが支払ったらサービスが確実に提供される」という信頼がなければ、取引は成立しません。

しかし、AIは銀行口座を開けない

ここで重大な問題が浮上します。現在の金融システムは、人間のために設計されています。

銀行口座を開設するには、KYC（本人確認）が必要です。パスポートや運転免許証で本人であることを証明しなければなりません。法人口座には法人格が必要です。AIエージェントには、どちらもありません。

クレジットカードを作るにも、社会保障番号や信用情報が必要です。国際送金にはSWIFTネットワークを使いますが、手数料は数千円、処理に1〜3営業日かかります。AIエージェントが0.1円の少額決済を毎秒行うような世界には、まったく対応できない仕組みです。

ブロックチェーンが唯一の解

ここで、ブロックチェーンが登場します。

ブロックチェーンの世界では、銀行口座の代わりに「ウォレット」があります。ウォレットの作成にKYCは不要です。秘密鍵（ランダムな数列）を生成するだけで、誰でも——人間でもAIでも——即座にウォレットを持てます。

スマートコントラクトが契約の役割を果たします。「サービスが完了したら自動的に報酬を支払う」というルールをコードで定義し、誰も改ざんできない形で実行される。信頼は人間関係ではなく、数学とコードによって保証されます。

暗号通貨が決済手段になります。L2技術により、0.01円以下の超少額決済も数秒で完了します。24時間365日、国境を越えて、即座に決済できる。

まとめると、こういう構図です。

【従来の金融システム】
人間 → 銀行口座(KYC必要) → 送金(手数料高い/遅い) → 契約(弁護士必要)

【ブロックチェーンの世界】
AIエージェント → ウォレット(KYC不要) → 送金(数円/数秒) → スマートコントラクト(自動執行)

つまり、ブロックチェーンはAIエージェントが経済活動を行うための唯一の実用的なインフラなのです。これが「3つの技術が交差する必然」の正体です。

市場が証明する必然性

この交差は、理論だけでなく市場データにも表れています。自律型AIエージェントの市場規模は、2024年の8,007億円から2030年には7.39兆円に達すると予測されています（年平均成長率約44%）。ブロックチェーン市場も同様に急拡大しており、特にDeFi（分散型金融）やエージェント向けインフラの分野で顕著な成長が見られます。

Webの進化として見る

最後に、この3つの技術の交差を「Webの進化」という大きな文脈で捉えてみましょう。

Web 1.0（1991-2004）: 読む — 静的なWebページを閲覧する時代
Web 2.0（2004-2014）: 書く — SNS、ブログ、動画投稿。ユーザーがコンテンツを創る時代
Web 3.0（2014-現在）: 所有する — ブロックチェーンでデジタル資産を所有する時代
Web 4.0（2025- ）: 行動する — AIエージェントが自律的に経済活動を行う時代

Web 1.0から2.0への転換は「読者が書き手になった」こと。Web 2.0から3.0への転換は「ユーザーがデータを所有できるようになった」こと。そしてWeb 3.0から4.0への転換は「AIが人間に代わって行動するようになる」ことです。

Web 4.0では、ブロックチェーンが信頼のインフラを、AIが知能を、エージェントが行動力を提供します。3つの技術がそれぞれの欠点を補い合い、一つの統合された新しいインターネット体験を生み出す。これが、次のインターネット革命の姿です。

この連載で伝えたいこと

連載「Web 4.0への道」の全体像

本連載は全12記事、4部構成で、ブロックチェーン・AI・AIエージェントが融合する「エージェント経済」の全体像を描きます。

第1部: 基礎編（記事0-2） — 3つの技術を個別に理解し、交差の必然性を知る。本記事はその出発点です。続く記事1では「なぜAIエージェントにお金が必要なのか」を掘り下げ、記事2では「AIエージェント同士が実際にどんな仕事を生み出しているのか」を具体例で解説します。

第2部: 実践編（記事3-5） — 理論から実践へ。実際のツール、設計パターン、セキュリティを解説し、エージェント経済への参加方法を示します。

第3部: 社会実装編（記事6-8） — 日本のSociety 5.0との接続、リスクと倫理を議論し、社会的なインパクトを俯瞰します。

第4部: 未来予測編（記事9-11） — Web 1.0から4.0への進化史を完成させ、2030年までの未来地図を描き、連載を締めくくります。

各記事は独立して読めるように設計していますが、前の記事の概念が次の記事の前提になる部分もあります。可能であれば、第1部から順に読んでいただくことをお勧めします。

筆者のポジション

最後に、筆者の立場を明確にしておきます。

筆者は暗号資産トレーダーではありません。AIエージェントビルダーです。

先ほど触れたAEGISは、61体のAIエージェントで構成された組織です。CEO、CTO、CFO、マーケター、エンジニア、セキュリティ専門家——人間の企業組織と同じ構造を持ち、コンテンツ制作からコードレビュー、市場分析、リスク評価まで、多岐にわたる業務を自律的に遂行しています。オペレーターは筆者1人です。

この連載は、61体のエージェント組織を日々運営する中で見えてきた「エージェントが本当に自律的になるには何が必要か」という問いへの回答です。投機的な暗号資産の話ではなく、実践に基づいたエンジニアリングの視点から、エージェント経済の現在と未来を解き明かしていきます。

「学びの旅路」として正直に発信します。筆者もまだこの領域のすべてを理解しているわけではありません。連載を進める中で新しい発見があれば、それも包み隠さず共有します。

次回予告: 第1回「AIエージェントにお金が必要な理由」では、エージェントの自律行動と経済活動の関係をさらに深掘りします。なぜ既存の金融システムではダメなのか。ブロックチェーンが解決する5つの具体的な課題とは何か。そして、すでに始まっているエージェント経済の市場規模について解説します。

If this helped you, consider giving it a heart!
Follow for more AI agent development content.

gstack vs Superpowers vs AEGIS — 3 Philosophies of AI Agent Systems

TAKUYA HIRATA — Fri, 27 Mar 2026 07:15:59 +0000

Quick Comparison

	gstack	Superpowers	AEGIS
Creator	Garry Tan (YC President)	Jesse Vincent (obra)	AEGIS Contributors
GitHub Stars	~23K+ (7 days)	~40K+	New (PyPI: aegis-gov)
Philosophy	Startup sprint workflow	Engineering methodology	Constitutional governance
Approach	15 opinionated skills as roles	TDD + debugging + brainstorming framework	Boardroom meetings + rule engine + red team
Governance	None (trust the workflow)	Methodology-enforced discipline	Explicit rules, verdicts, audit trails
Agent Count	6 virtual roles	Subagent-driven (dynamic)	9 default + 8 specialists (17 council members)
Scalability	Solo developer / small team	Solo to small team	Solo to enterprise (140+ agents in full version)
Learning Curve	Low — copy skills, run commands	Medium — understand methodology first	Medium — understand governance model
LLM Support	Claude Code (+ Codex, Gemini CLI)	Claude Code primary	Anthropic, OpenAI, Ollama (any LLM)
License	MIT	MIT	Apache 2.0

gstack: The Startup Sprint

What it is: Garry Tan's personal Claude Code setup, open-sourced. 15 opinionated workflow skills that turn Claude Code into a virtual engineering team — CEO, Designer, Eng Manager, Release Manager, Doc Engineer, QA.

The philosophy: AI agents work best when they follow the same sprint cadence that works for human teams. Think, Plan, Build, Review, Test, Ship, Reflect.

Strengths

Immediate productivity. Copy the skills, run the commands, ship code. gstack hit 23K stars in a week because it delivers instant value. No configuration ceremony — just /office-hours to think, /plan-ceo-review to plan, /ship to deploy.

Real-world provenance. This is how the president of Y Combinator actually builds software. It's not theoretical — it's battle-tested on real products.

Browser-first architecture. gstack runs a persistent Chromium daemon with sub-second latency. This is genuinely hard engineering — the browser doesn't cold-start between commands, so QA testing and visual reviews are fast and stateful.

Cross-agent compatibility. Through the SKILL.md standard, gstack works with Claude Code, Codex, Gemini CLI, and Cursor.

Limitations

No governance layer. There's no mechanism to prevent an agent from taking a harmful action. The workflow assumes good outcomes follow good process, which is true until it isn't.

Copy-paste culture risk. 23K stars in a week means thousands of developers are running one person's opinionated workflow without modification. gstack is Garry Tan's brain — your team might need a different brain.

Solo-focused. The skills are designed for a single developer working with AI. There's no multi-agent coordination, no conflict resolution, no audit trail for team accountability.

Superpowers: The Methodology

What it is: An agentic skills framework and software development methodology. More installs than Playwright on the Claude Code marketplace. 40K+ stars.

The philosophy: The bottleneck in AI-assisted development isn't model capability — it's methodology. If you teach agents disciplined engineering practices, they earn your trust.

Strengths

Trust through discipline. Superpowers enforces red-green-refactor TDD cycles where tests must fail before implementation. It requires root cause investigation before any fix. It runs Socratic brainstorming sessions that refine requirements before coding begins. This is genuine engineering methodology, not vibes.

Subagent-driven development. Once you approve the plan, Superpowers launches subagents to work through each task, inspecting and reviewing their work before continuing. The implementation plan is deliberately written for "an enthusiastic junior engineer with poor taste, no judgement, and an aversion to testing" — meaning the instructions are unambiguous enough for any agent to follow.

Compound learning. Each development cycle documents learnings for future AI agent consumption. 80% of developer time goes to planning and review, systematically creating a self-improving system.

Strong community. 40K+ stars and active development mean continuous improvement, community skills, and broad compatibility.

Limitations

Single-user scope. Like gstack, Superpowers is designed for a developer working with their AI agent. It doesn't address multi-agent governance, cross-team coordination, or organizational-scale decision making.

No enforcement mechanism. The methodology is advisory — agents follow it because the prompts tell them to. There's no rule engine that can BLOCK an action, no HALT that stops all processes, no human escalation gate that requires approval.

Methodology, not governance. Superpowers ensures agents build well. It doesn't ensure they should build at all. There's no red team challenging whether the decision itself was correct.

AEGIS: The Constitution

What it is: A governance-first framework where AI agents debate decisions in structured boardroom meetings, face mandatory red team review, and operate under constitutional rules with enforceable verdicts.

The philosophy: Every other multi-agent framework helps AI agents do things. AEGIS makes sure they should.

Strengths

Enforceable governance. AEGIS has a 5-verdict rule engine (PASS, FLAG, BLOCK, ESCALATE_TO_HUMAN, HALT) that prevents actions, not just advises against them. Self-review is blocked. Low-confidence decisions are flagged. Production deployments without review are escalated to humans.

from aegis_gov import RuleEngine

engine = RuleEngine()
# Production deploy without review? -> ESCALATE_TO_HUMAN
engine.evaluate("DevOps", "deploy", {
    "environment": "production",
    "tests_passed": True,
    "review_approved": False,
})

Mandatory red team. Every decision faces a DevilsAdvocate (challenges assumptions, demands evidence) and a Skeptic (explores alternatives, runs pre-mortem analysis). The red team cannot be disabled in the default configuration.

Structured decision-making. 17 AI agents with distinct roles debate every decision across 6 phases: CEO Opening, Executive Council (7 C-level perspectives), Advisory Input (8 specialists), Critical Review (red team), Open Debate, and CEO Synthesis with vote tally and confidence score.

Compliance-ready. The audit trail, decision categorization, and human escalation gates map directly to EU AI Act, NIST AI RMF, and ISO 42001 requirements.

LLM-agnostic. Works with Anthropic, OpenAI, or any OpenAI-compatible API (including local models via Ollama).

Limitations

Overhead for small projects. If you're a solo developer building a side project, a 17-agent boardroom meeting is overkill. gstack or Superpowers will get you shipping faster.

Newer project. AEGIS doesn't have 40K stars (yet). The community is smaller, and the ecosystem is younger.

Governance adds latency. A full boardroom meeting with red team review takes time. For rapid prototyping, you want speed. For production decisions with real consequences, you want governance.

When to Use Which

Scenario	Best Choice	Why
Solo developer, ship fast	gstack	Instant productivity, proven workflow
Engineering team, build trust in AI	Superpowers	TDD methodology, compound learning
Multi-agent systems, need accountability	AEGIS	Governance, audit trails, enforcement
Compliance-sensitive industry	AEGIS	EU AI Act / NIST / ISO alignment
Learning AI-assisted development	Superpowers	Best teaching methodology
Startup MVP sprint	gstack	Fastest path from idea to deploy
Production decisions with real consequences	AEGIS	Red team + rule engine + human escalation

The Combination Play

These tools are not mutually exclusive. The strongest setup might be:

gstack for your sprint workflow (Think, Plan, Build)
Superpowers for your engineering methodology (TDD, debugging, brainstorming)
AEGIS as the governance layer on top (Can we? Should we? Who approves?)

AEGIS is explicitly designed to be "the governance layer you add on top" of existing frameworks.

Try AEGIS

pip install aegis-gov
aegis convene "Should we mass-email all users about the new feature?" --category TACTICAL

GitHub: github.com/pyonkichi369/aegis-oss
PyPI: pypi.org/project/aegis-gov
License: Apache 2.0

Want the full 140-agent configuration with 148 optimized prompts? The AI Agent Prompts Pack includes production-ready agent definitions, constitutional governance templates, and the complete AEGIS organizational structure.

What's your approach to AI agent governance? Are you in the "trust the workflow" camp, the "enforce methodology" camp, or the "constitutional governance" camp? Drop a comment below.

I Gave 140 AI Agents a Constitution and a Kill Switch

TAKUYA HIRATA — Fri, 27 Mar 2026 03:46:14 +0000

TL;DR

I built 140 AI agents on top of Claude Code, organized into 4 boards, 18 organizations, with a constitution, security halt authority, and autonomous decision-making. 367 tests, 135K lines of Python, and it actually runs. This article covers the design philosophy, technical choices, and spectacular failures — nothing held back.

Why 140 Agents?

Using ChatGPT or Claude as a single assistant, I noticed something: AI performs dramatically better as a team of specialists than as one generalist.

Security reviews, article writing, video production, code reviews, tax processing — cramming all of this into one prompt makes everything mediocre. Just like human organizations, specialization + governance is the key to quality.

Operator (human) — final authority
    |
Secretary (/ask) — intent parsing → routing
    |
4 Domain Boards — each Chairman owns strategic decisions
    |
    ├── App Board ──→ Product(10), Design(6), Operations(6), Security(6), LLM(8)
    ├── Game Board → Game Design(4), Engineering(3), Creative(3)
    ├── Content Board → Content(6), Revenue(11), Marketing(6), Creative(13), Education(7)
    └── Shared Board → Backoffice(7), Research(7), Oracle(3), Autonomous(8), User Testing(21)

Total: 135 org agents + 5 Holdings = 140 agents

This structure wasn't built to look impressive. Specialized agents consistently outperformed generalist ones — that's the evidence that led to this design.

Architecture: Protocol-Driven Composition

The AEGIS engine layer (98K LOC) uses Protocol + Composition + DI — a strategic choice to avoid inheritance hell.

Why Protocols?

# DON'T: Inheritance-based (leads to pain)
class BaseAgent(ABC):
    @abstractmethod
    def execute(self): ...

class SecurityAgent(BaseAgent):
    def execute(self): ...

class SecurityPentester(SecurityAgent):  # Multi-level inheritance → hell
    def execute(self): ...

# DO: Protocol + Composition (AEGIS actual pattern)
from typing import Protocol

class WorkflowEngineProtocol(Protocol):
    """Interface definition only — implementation is free"""
    def execute_workflow(self, workflow_id: str, context: dict) -> dict: ...
    def get_status(self, execution_id: str) -> dict: ...

class LangGraphEngine:
    """Protocol-compliant implementation A"""
    def execute_workflow(self, workflow_id, context):
        return self._langgraph_execute(workflow_id, context)

class NativeEngine:
    """Protocol-compliant implementation B — no LangGraph needed"""
    def execute_workflow(self, workflow_id, context):
        return self._native_execute(workflow_id, context)

# Injected via DI — switchable at runtime
container.register(WorkflowEngineProtocol, NativeEngine, Lifetime.SINGLETON)

The advantage: mocking is trivial in tests. External dependencies are abstracted behind Protocols, so you can test the entire pipeline without an LLM.

Three Layers, One Design Principle Each

Layer	LOC	Pattern	Design Principle
Engine	98K	Protocol + Composition + DI	Extensibility through abstraction
API	20K	FastAPI pragmatic monolith	Thin Router → Service → ORM
UI	12K	Vanilla ES6 functional modules	Named exports, module closures

One design principle per layer. This is critical. Initially, I tried applying DDD to every layer and failed. In practice, the API layer didn't need DDD — Pragmatic Layered Architecture was sufficient.

Composition Over Inheritance in Practice

Here's what composition looks like with 140 agents:

# Mixins for cross-cutting concerns
class SerializableMixin:
    def to_dict(self) -> dict:
        return dataclasses.asdict(self)

    @classmethod
    def from_dict(cls, data: dict):
        return cls(**data)

class CallbackMixin:
    def __init__(self):
        self._callbacks: dict[str, list] = {}

    def on(self, event: str, callback):
        self._callbacks.setdefault(event, []).append(callback)

    def emit(self, event: str, *args):
        for cb in self._callbacks.get(event, []):
            cb(*args)

# Components compose these behaviors
class BaseComponent(SerializableMixin, CallbackMixin):
    """Base for all pipeline components — no inheritance chain"""
    pass

No abstract base classes. No 5-level inheritance trees. Just composition of small, focused behaviors.

Governance: The Missing Layer in Every AI Framework

The 4-Level Decision Model

# Decision authority levels
OPERATIONAL: Agent decides automatically (status checks, log entries)
TACTICAL:    Org CEO decides (feature implementation, content publishing)
STRATEGIC:   Chairman + human CONFIRM (architecture changes, org restructuring)
CRITICAL:    Human HALT (security breach, data loss, credential exposure)

The most important rule: Security HALT — the Security org can stop every other org instantly. This overrides everything, including revenue priorities.

Auto-Approval System

Not every decision needs human input. The system classifies risk automatically:

# Auto-approval routing
approval_rules = {
    "status_check":    "AUTO",     # Low risk, reversible → execute silently
    "content_publish": "NOTIFY",   # Medium risk → execute, summarize daily
    "pricing_change":  "CONFIRM",  # High risk → require human approval
    "security_breach": "HALT",     # Critical → block everything immediately
}

This is what's missing from CrewAI, LangGraph, and AutoGen. When you have 140 agents, you need governance. Without it, agents propose conflicting strategies, make contradictory decisions, and nobody knows who has authority.

The Pipeline: 6-Stage Relay Processing

Every query passes through 6 organizations in sequence:

[Market Intelligence] → [Strategy (Go/No-Go)] → [Product] → [Technology] → [Execution] → [Validation]

Each stage is protected by an independent circuit breaker. If one breaks, the others keep running.

class StageCircuitBreaker:
    """Independent circuit breaker per pipeline stage"""
    def __init__(self, failure_threshold=3, cooldown=60):
        self.state = "closed"  # closed → open → half_open
        self.failure_count = 0

    def call(self, func, *args):
        if self.state == "open":
            if time.time() - self.last_failure > self.cooldown:
                self.state = "half_open"  # Allow retry
            else:
                raise CircuitOpenError(f"Circuit open for {self.stage}")
        try:
            result = func(*args)
            self._on_success()
            return result
        except Exception as e:
            self._on_failure()
            raise

If the pipeline fails mid-way, you can resume from the last completed stage:

# First run (fails at Stage 3)
make org-pipeline QUERY="AI marketplace"
# → Stage 1 PASS, Stage 2 PASS, Stage 3 FAIL

# Resume from checkpoint
python3 orchestrator.py --resume run_20260327_143022
# → Stage 1 (skip), Stage 2 (skip), Stage 3 → 6 (re-run)

Writing 367 Tests in One Day with Parallel Agents

Nobody enjoys writing tests. But with 140 agents, running without tests is suicide.

The Problem

Early on, we had only 24 tests. A bug in pipeline_resilience.py would only surface when production broke.

The Solution: Parallel Agent Test Generation

Claude Code has an Agent tool for spawning parallel workers. I used it to write tests with 5 agents simultaneously:

Agent 1: Schema validation tests    → 82 tests (JSON parsing, all schemas)
Agent 2: Pipeline resilience tests   → 22 tests (circuit breaker, retry, health)
Agent 3: Stage 3-6 unit tests       → 45 tests (input/output per stage)
Agent 4: MCP tool tests             → 34 tests (all 8 MCP tools covered)
Agent 5: E2E integration tests      → 41 tests (full pipeline integration)

Result: 338 tests in one day. Subsequent features brought the total to 367.

Why Parallelism Works for Tests

Test files have minimal interdependencies. Agent 1 writing schema tests doesn't conflict with Agent 4 writing MCP tests. If I asked 5 agents to write the same article, they'd collide (same file). Match task structure to parallelism — that's the key insight.

Test execution results:
test_schemas.py          — 82 tests
test_pipeline_resilience — 22 tests
test_stages.py           — 45 tests
test_mcp_tools.py        — 34 tests
test_parallel_pipeline   — 14 tests
test_e2e_pipeline.py     — 41 tests
test_browser_agent       — 68 tests (SSRF defense, URL validation)
+ additional tests        — 61 tests
─────────────────────────
Total                     367 test methods
Full test run time: ~9 seconds

Adding Revenue Specialist Agents

AEGIS started with 136 agents but zero revenue. A technically beautiful system that can't sustain itself is a hobby, not a business.

The Root Problem

The generic revenue_ceo could talk strategy but didn't know platform-specific tactics. "Sell on Coconala" is useless advice without understanding the search algorithm, pricing norms, or review mechanics.

4 Revenue Specialist Agents

# Revenue org additions
coconala_specialist:
  focus: "Coconala listing optimization, pricing, search algorithm, review acquisition"
  # Coconala search ranks by: favorites × sales × reviews
  # Strategy: dump pricing initially to build track record

gumroad_specialist:
  focus: "Gumroad product design, 3-tier pricing, external traffic, email optimization"
  # Getting on Gumroad Discover = organic traffic
  # 3-tier pricing: $9.99 / $24.99 / $49.99

# Education org additions
menta_specialist:
  focus: "MENTA plan design, niche positioning, retention optimization"
  # Position: "Claude Code × solopreneur" — ultra-niche
  # Free consultation → monthly subscription conversion

udemy_specialist:
  focus: "Udemy course design, bestseller strategy, self-promotion 97% revenue"
  # Self-referral links keep 97% of revenue
  # Target niche keywords for search visibility

Key decision: don't add knowledge to a generalist — create separate specialists. Coconala's pricing strategy and Gumroad's pricing strategy are fundamentally different. Each platform has its own rules.

Agent Prompt Design: The 3-Layer Architecture

Shared Protocols (Injected into All 140 Agents)

# _shared_protocols.md (every agent gets this)
- Constitutional compliance: manifesto violation = HALT
- Confidence disclosure: 0.9+ → proceed, 0.7-0.89 → note uncertainty, <0.5 → don't present as fact
- Anti-hallucination: verify file existence before reference, cite sources for metrics
- Security: hardcoded secret = HALT

Individual Agent Specialization

# pentester.prompt (example)
## ETHICAL GUARDRAILS (absolute)
- Test only authorized systems
- No destructive actions — stop at vulnerability confirmation
- No DoS, no data exfiltration
- Include remediation for every finding

The 3-Layer Structure

Layer 1: _shared_protocols.md  (all agents — constitution)
Layer 2: org_agents.yaml       (org level — authority, constraints, KPIs)
Layer 3: <agent_name>.prompt   (individual — expertise, prohibitions)

Why 3 layers? I started with 6. Result: LLMs ignored 30% of the rules. The deeper the layer, the weaker the enforcement. 3 layers is the sweet spot.

CrewAI / LangGraph / AutoGen vs. AEGIS

"Why not just use CrewAI or AutoGen?" I tried all of them. Here's the honest comparison:

Aspect	CrewAI	LangGraph	AutoGen	AEGIS
Agent definition	Python class	Graph node	ConversableAgent	Markdown prompts
Governance	None	None	None	4-level decisions + constitution
Safety stop	None	None	None	Security HALT (immediate)
Scale ceiling	~10 agents	~20 nodes	~10 agents	140 (on-demand loading)
LLM cost	All cloud	All cloud	All cloud	90% local ($0)
Testability	Low	Medium	Low	High (Protocol abstraction)
Learning curve	Low	High	Medium	High

The Governance Gap

With 10 CrewAI agents, everyone speaks equally. There's no mechanism to stop a proposal with security risks. In AEGIS, security_ceo can halt all orgs instantly.

# CrewAI approach
crew = Crew(agents=[dev, reviewer, deployer])
crew.kickoff()  # → Who makes the final call? Security?

# AEGIS approach
# security_ceo issues HALT → all orgs stop → escalate to human
# 14-Day Revenue Rule < Security HALT (explicit priority ordering)

The Prompt Management Problem

In CrewAI and AutoGen, agent prompts live inside Python code. Managing 140 prompts inside Python files is hell. In AEGIS, every prompt is an independent .prompt file. Non-engineers can edit prompts too.

The Cost Problem

Other frameworks assume cloud LLM APIs. AEGIS defaults to Ollama (local LLM) and processes 90% of daily work at $0.

# LLM routing
OPERATIONAL: qwen2.5:14b (Ollama, local, $0)
TACTICAL:    Claude Sonnet 4.6 (cloud)
STRATEGIC:   Claude Opus 4.6 (cloud)

Honest Conclusion

For 5 or fewer agents, CrewAI is enough. Low learning curve, quick results.

For 10+ agents with governance needs — existing frameworks fall short. You need custom design like AEGIS. This isn't "AEGIS is better" — it's "the problem scale is different."

Cost Optimization: Running at $0/month

# Adapter Pattern for gradual migration
LLM:     Ollama($0) → Claude API(paid) — switch via env var
DB:      SQLite($0) → PostgreSQL(paid) — swap adapter
Storage: Filesystem($0) → S3/R2(paid) — swap adapter
Cache:   In-memory($0) → Redis(paid) — swap adapter
TTS:     Edge TTS($0) → ElevenLabs(paid) — swap adapter

90% of daily operations run on local LLM. M1 Max 64GB handles it comfortably. Cloud is reserved for important decisions only.

# Minimal startup (no Docker required)
make dev-minimal
# → AEGIS OS pipeline runs on Ollama alone

Why This Matters for Solo Developers

If you're a solopreneur building AI tools, cloud API costs compound fast. At 140 agents making decisions throughout the day, even cheap models add up. The Adapter Pattern lets you start at $0 and upgrade selectively:

# Environment-based LLM switching
import os

LLM_PROVIDER = os.environ.get("LLM_PROVIDER", "ollama")

if LLM_PROVIDER == "ollama":
    client = OllamaClient(base_url="http://localhost:11434")
elif LLM_PROVIDER == "anthropic":
    client = AnthropicClient(api_key=os.environ.get("ANTHROPIC_API_KEY", ""))

Failures and Lessons

Failure 1: "Write Rules and They'll Follow" Is a Fantasy

I wrote a 200-page rulebook. Result: LLMs ignored 30% of the rules.

Fix: Reduced from 6 layers to 3. Emphasized only critical rules. "Don't do X" is more effective than "Do Y" for LLMs.

Failure 2: Too Many Agents

Initially, I believed "more agents = higher quality." Reality:

Communication overhead exploded
Context windows consumed just by loading configurations
40% of agents were never used

Fix: Instead of deleting unused agents, switched to on-demand loading. Only 20-30 agents run constantly. The rest sleep until needed.

Failure 3: Zero Revenue

30+ articles published. Gumroad products created. Zero sales.

Root cause: zero traffic. Great content that nobody reads doesn't sell.

Lesson: Content generation AI automates "writing" but can't automate "getting read." Distribution and marketing are the real bottlenecks.

Failure 4: Token Waste

Every conversation burned ~6,000 tokens just loading rules. Usable context was severely limited.

Fix: Compressed all config files by 69% (1,609 → 494 lines). Prompts compressed by 29% (22,262 → 15,814 lines). Zero information loss.

Failure 5: Docs vs. Reality Drift

Documentation said "146 agents" but reality was 136. User Testing org changed from 24 to 21 without updating docs.

Fix: Script that auto-counts from agents.yaml. Documentation-implementation mismatches are now auto-detected. Manual tracking always breaks.

By the Numbers

Metric	Value
Total agents	140 (135 org + 5 holdings)
Organizations	18 orgs across 4 boards
Python LOC	135,000+
Tests	367 methods
Test runtime	~9 seconds
Prompt files	139+ files
Context consumption	~2,000 tokens/conversation (after compression)
LLM cost (local)	$0/month
Revenue specialist agents	4 (coconala, gumroad, menta, udemy)

Tech Stack

Engine design:      Protocol + Composition + DI (Python)
Agent definitions:  Markdown prompts (.prompt) x 140
Pipeline:           Python (asyncio + ThreadPoolExecutor)
LLM:                Ollama (qwen2.5:14b) + Claude API (fallback)
Config:             YAML (ai_config.yaml, agents.yaml)
Tests:              pytest (367 tests, ~9s)
Search:             SearXNG (self-hosted)
MCP:                FastMCP (8 tools)
API:                FastAPI (20K LOC, 12 routers)
UI:                 Vanilla ES6 modules (12K LOC)
CI:                 GitHub Actions + detect-secrets + pip audit

How to Reproduce This

You don't need to build 140 agents from day one. Start with the pattern:

Step 1: Define Your First 3 Agents as Prompts

# prompts/code_reviewer.prompt
You are a senior code reviewer. Focus on:
- Security vulnerabilities (OWASP Top 10)
- Performance anti-patterns
- Maintainability concerns
Never approve code with hardcoded secrets.

# prompts/content_writer.prompt
You are a technical content writer. Focus on:
- Developer audience (practical, code-heavy)
- SEO-optimized titles and structure
- Include working code examples in every section
Never publish without proofreading for factual accuracy.

# prompts/security_auditor.prompt
You are a security auditor with HALT authority.
You can stop any deployment if you find:
- Hardcoded credentials
- SQL injection vectors
- Missing authentication checks
Your HALT overrides all other priorities.

Step 2: Add Protocol-Based Routing

from typing import Protocol

class AgentProtocol(Protocol):
    def process(self, query: str, context: dict) -> dict: ...

class PromptAgent:
    def __init__(self, prompt_path: str, llm_client):
        self.prompt = open(prompt_path).read()
        self.llm = llm_client

    def process(self, query: str, context: dict) -> dict:
        response = self.llm.complete(
            system=self.prompt,
            user=query,
            context=context
        )
        return {"agent": self.name, "result": response}

# Route by intent
router = {
    "review": PromptAgent("prompts/code_reviewer.prompt", llm),
    "write":  PromptAgent("prompts/content_writer.prompt", llm),
    "audit":  PromptAgent("prompts/security_auditor.prompt", llm),
}

Step 3: Add Governance When You Hit 10+ Agents

That's when you need decision levels, security halt, and auto-approval. Not before.

Repository Structure

aegis/
├── engine/                      # Engine (98K LOC)
│   ├── organizations/           # AEGIS OS pipeline (10K LOC)
│   ├── common/                  # DI, circuit breaker, protocols
│   └── external/                # External integrations
├── orgs/                        # 18 organizations × agent prompts
│   ├── revenue/                 # Revenue org (11 agents)
│   ├── security/                # Security org (6 agents)
│   └── ...
├── holdings/                    # Governance (Secretary, 4 Chairmen)
├── prompts/                     # Shared protocols
├── config/organizations/        # LLM configuration
├── services/api/                # FastAPI (20K LOC)
└── ui/public/                   # Vanilla ES6 UI (12K LOC)

# Minimal startup
make dev-minimal  # Ollama only, no Docker required

# Run the pipeline
make org-pipeline QUERY="AI agent marketplace"

# Run tests
python3 -m pytest engine/organizations/tests/ -v
# → 367 passed in ~9s

Key Takeaways

Specialization works for LLMs — A team of specialist AIs outperforms one generalist
Governance is mandatory — Uncontrolled AI agents will conflict and hallucinate without authority structures
Tests are everything — 367 tests are the only reason I dare touch the codebase
Cost can be zero — Local LLMs handle 90% of daily operations
Framework choice < Design principles — If CrewAI/AutoGen isn't enough, build custom. But for 5 agents, CrewAI is fine
Building isn't enough — The biggest failure was assuming "build it and they will come"
Platform specialists beat generalists — Coconala tactics and Udemy tactics are completely different

Get the Full Blueprints

If you want to implement a similar system, I've published comprehensive resources:

56 AI Agent Prompts Pack ($24.99) — Copy-paste ready prompts for code review, security audit, content writing, revenue optimization, and more. All battle-tested across 140 agents.
Full Design Blueprints (note.com) — Complete governance rules, prompt templates, cost optimization configs, and a reusable starter kit.

Questions or feedback? Drop a comment. I read every single one.

This article was routed through AEGIS Secretary to the Content Board for writing. The article itself is AEGIS output.

AIエージェント週報 — 2026年3月第4週 — Road to Web 4.0

TAKUYA HIRATA — Sun, 22 Mar 2026 04:37:04 +0000

今週のAIエージェント界隈で起きたことを、116体のAIを運営するオペレーターが解説する。
ニュースの表面だけでなく、「で、実際どうなの？」まで踏み込みます。
毎週読めば、AI業界の動きが手に取るようにわかるようになります。

僕はTAKUYA。合同会社AJARAの代表で、AIエージェント組織「AEGIS」を運営しています。毎日エージェントと働いている立場から、今週のニュースを解説します。

1. Claude Opus 4.6 の実力

Anthropicが3月にリリースしたClaude Opus 4.6は、エージェント用途で確実に進化しています。特に100万トークンのコンテキストウィンドウは、大規模コードベースの分析で威力を発揮する。

AEGISでは戦略的な意思決定（ボードルーム会議、アーキテクチャ設計）にOpus 4.6を使っています。体感として、複雑な文脈の理解力が前バージョンより明らかに上がっています。

TAKUYAの見解。モデルの進化は「性能が上がった」だけでは語れない。Opusクラスのモデルが登場するたびに、エージェントに任せられる仕事の範囲が広がる。これが本当の意味での進化です。

2. Google A2Aプロトコルの広がり

GoogleのAgent-to-Agent（A2A）プロトコルの採用が着実に広がっています。異なるベンダーのAIエージェント同士が標準的な方法で通信できるようになる。

これはインターネットにおけるHTTPのようなものです。プロトコルが標準化されれば、エージェントの相互運用性が一気に高まる。

TAKUYAの見解。AEGISは現在、内部的な独自プロトコルで14組織を連携させています。A2Aが成熟したら、外部のエージェントとも連携できるようになる。1人会社のエージェントが、他社のエージェントと協働する未来が見えてきました。

3. エージェントマーケットプレイスの成長

AIエージェントを売買・共有するマーケットプレイスが増えています。特定の業務に特化したエージェントを購入して、すぐに自社の業務に組み込める。

SaaS時代は「ソフトウェアを買う」だった。エージェント時代は「労働力を買う」になる。この変化は巨大です。

TAKUYAの見解。AEGISの116体は全て自前で構築していますが、マーケットプレイスの成熟次第では外部エージェントの導入も検討します。ただし、セキュリティの検証は必須。他人が作ったエージェントを無検証で信頼するのは危険です。

4. 各国の規制動向

EUのAI規制（EU AI Act）の施行が進む中、日本でもAIエージェントに関する議論が活発化しています。特に「エージェントが自律的に契約行為を行う場合の法的責任」が論点になっている。

AIエージェントが発注や支払いを自動で行うとき、責任は誰にあるのか。運営者か、開発者か、AIそのものか。まだ答えは出ていません。

TAKUYAの見解。法整備を待っていたら遅い。AEGISでは「戦略的決定は必ず人間が承認する」というルールを設計に組み込んでいます。技術的にできることと、やっていいことは別。自主規制が先です。

5. AEGIS内部アップデート

今週のAEGIS。コンテンツ制作パイプラインの強化を進めています。note.comでの記事発信を本格化し、AIエージェントの実践知を日本語で届ける活動を拡大中。

116体のエージェントと14組織という規模で運営している知見は、日本ではほぼ唯一です。この経験を共有することで、エージェント活用のハードルを下げたいと思っています。

来週も引き続き、revenue組織の最適化とコンテンツの量産体制構築に注力します。

今週のまとめ

AIエージェント業界は、インフラ層（プロトコル、マーケットプレイス）とアプリケーション層（実際の業務活用）の両方が同時に成長しています。

来週もこの週報で最新動向をお届けします。AIエージェントの世界で何が起きているか、毎週キャッチアップしたい方はフォローしてください。記事が参考になったら「スキ」を押してもらえると嬉しいです。

Tags: #AI #ニュース #AIエージェント #週報 #テクノロジー

Claude Code 実践テンプレート集 — コピペで使える設定とワークフロー — Road to Web 4.0

TAKUYA HIRATA — Sun, 22 Mar 2026 04:36:54 +0000

Claude Codeを3ヶ月間、毎日8時間使い続けた。

その中で磨き上げたテンプレートを全公開する。

テンプレートがあるかないかで、AIの出力品質は根本的に変わる。設定ファイルのコピペだけで生産性が2倍になる。大げさではない。

なぜテンプレートが重要なのか

Claude Codeは賢い。しかし、何も指示しなければ「賢いが方向性のない」出力をする。

CLAUDE.mdにルールを書いておけば、全ての会話で自動的に読み込まれる。一度書けば、永久に効く。

この記事に含まれるテンプレートは6つだ。

1つ目はCLAUDE.md。プロジェクト全体のルールを定義する。これが土台になる。2つ目はスキル定義。再利用可能なワークフローを自動化する。3つ目はエージェントプロンプト。AI人格と権限を定義する。4つ目はフック設定。コミット時の自動チェックを仕込む。5つ目はマルチエージェント連携。複数AIの協調ルーティング。6つ目は品質ゲート。7段階の自動検証チェックリスト。

全て、僕が実際に毎日使っているテンプレートがベースだ。

無料サンプル: CLAUDE.md 基本構造

まずは誰でも使える基本テンプレートを公開する。

# CLAUDE.md

## プロジェクト概要
[プロジェクト名]は[目的]のための[種類]です。

## 技術スタック
- 言語: [Python/TypeScript/etc]
- フレームワーク: [FastAPI/Next.js/etc]

## コーディング規約
- ファイル上限: 300行（超えたら分割）
- 命名: snake_case（Python）/ camelCase（JS）
- エラー: 例外は握りつぶさない、構造化ログに記録

## セキュリティ
- シークレットは絶対にコードに書かない
- 環境変数経由（デフォルト値は空文字列）

## 禁止事項
- [プロジェクト固有の禁止パターン]

これだけでも出力は格段に改善される。

僕が最初にCLAUDE.mdを書いたとき、Claude Codeの出力が一気に安定した。それまではファイルごとにコーディングスタイルがバラバラだったのが、プロジェクト全体で統一された。

しかし、これは入口に過ぎない。実戦で3ヶ月使い込んだテンプレートは、レイヤー別ルール、意思決定記録、承認フロー、セキュリティゲートまで含む。

ここから先は有料です

テンプレート1: CLAUDE.md 実戦版

基本版との違いは、レイヤー別ルールと意思決定記録の組み込みだ。

レイヤー別に分ける理由は明確で、バックエンドとフロントエンドでは品質基準が全く違うからだ。

バックエンド層には3つのルールを入れる。まずファイルサイズ制限。ルーター300行、サービス400行を超えたら分割する。次にセキュリティテスト4パターン。未認証は401、権限不足は403、他テナントのデータアクセスは404（存在を漏らさないために403ではなく404）、不正入力は422。最後にDB操作のパターン。サービス関数がDBセッションを引数で受け取る形にする。

フロントエンド層にはデザイントークン変数のみ使用を定義する。ハードコードされたカラーコードやフォント名は禁止。アクセシビリティ基準として、タッチターゲット44px以上、コントラスト比4.5:1以上も明記する。

インフラ層には外部API呼び出しのタイムアウト5秒とフォールバック値、サーキットブレーカー（連続失敗5回で回路オープン）、全サービスへのヘルスチェックエンドポイント設置を定義する。

最も見落とされがちなのが「意思決定の記録」セクションだ。日付、決定内容、理由、却下した代替案を形式として定めておく。Claude Codeはこの記録を読んで、過去の判断と一貫した決定を下せるようになる。プロジェクトが長期化するほど、この蓄積が効いてくる。

テンプレート2: スキル定義

スキルは再利用可能なワークフローだ。一度定義すれば、関連するタスクで自動的に発動する。

トリガー条件をキーワードとファイルパターンで定義する。例えば「リファクタリング」「コード改善」というキーワードと、対象ファイルパターン「.py」「.ts」を指定しておく。

核心は4フェーズ構成だ。

フェーズ1の調査では、対象ファイルの読み込み、同ディレクトリの既存パターン確認、変更の影響範囲特定を行う。

フェーズ2の計画では、変更計画の策定、リスク評価、テスト計画を立てる。

フェーズ3の実行では、計画に沿って実装し、各ステップで検証する。

フェーズ4の検証では、lint実行、テスト実行、セキュリティスキャンを走らせる。

なぜ4フェーズが重要か。Claude Codeは指示が曖昧だと、調査を飛ばしていきなり実装に入ることがある。フェーズを明示することで、順序が保証される。

末尾にはチェックリストを付ける。既存パターンに従っているか、テストが通るか、セキュリティルール違反がないか、ファイルサイズ上限を超えていないか。完了条件を明確にすることで、中途半端な成果物を防ぐ。

テンプレート3: エージェントプロンプト

複数のAIを使い分けるときのプロンプト構造。

最も重要なのは「判断基準の優先順位」だ。例えばセキュリティエージェントなら「セキュリティ > コンプライアンス > 信頼性 > パフォーマンス」と定義する。矛盾する要求を受けたとき、何を優先するかが自動的に決まる。

権限スコープも明示する。自律実行可能なタスク、承認が必要なタスク、絶対に禁止するアクション。この3分類で暴走を防ぐ。

報告先、連携先、報告形式も定義しておく。エージェント間の通信が構造化される。

テンプレート4: フック設定

品質の自動化に欠かせない。pre-commitフックにシークレット検知（失敗時はblock）、リント（block）、型チェック（warn）を設定する。

post-tool-useフックでサプライチェーン検証を走らせる。環境変数の外部送信や疑わしいパッケージを自動検知する。

on_failure設定が鍵だ。シークレット検知は必ずblock。認証情報がコードに混入するのは、warnで済む問題ではない。

テンプレート5: マルチエージェント連携

複数のAIエージェントが協調する場合に不可欠なルーティング定義だ。

まずデフォルトのエントリーポイントを決める。全メッセージがまずセクレタリーを通る。セクレタリーはキーワードから意図を解析し、適切な組織にルーティングする。

ルーティングテーブルは意図ベースで定義する。「収益」「マネタイズ」ならレベニュー組織、「コード」「バグ」ならプロダクト組織、「セキュリティ」「脆弱性」ならセキュリティ組織。

SLAも優先度別に設定する。criticalは即時（SLAなし）、highは4時間以内、standardは24時間以内。SLAがなければ依頼は永遠に放置される。

最重要はhalt_authority。セキュリティ組織とバックオフィス組織にだけ、全組織を停止する権限を与える。この非対称な権限設計が、安全な自律運用を可能にする。

エスカレーションルールも忘れずに。組織間の対立は議長が裁定、タイムアウトはオペレーター（人間）に上げる。最終的な安全網は常に人間だ。

テンプレート6: 品質ゲート

7ステップの自動検証スクリプトだ。CIパイプラインに組み込む。

ステップ1は構文チェック。ステップ2はリント。ステップ3はシークレット検知。ステップ4は依存関係の脆弱性チェック。ステップ5はテスト実行。ステップ6はカバレッジ確認（最低80%）。ステップ7はレジリエンスチェック（タイムアウト設定、サーキットブレーカーの有無）。

ただし全てを毎回実行するのは非効率だ。変更規模でティア分けする。

1ファイルの変更ならリント + シークレット検知だけで十分。複数ファイルの変更ならテストを追加する。新プロジェクトや大規模リファクタリングなら全7ステップ実行。この段階的な適用が、開発速度と品質のバランスを取る鍵だ。

組み合わせ方

6つのテンプレートは組み合わせると真価を発揮する。ただし、最初から全部導入する必要はない。

まずCLAUDE.mdから始める。次にフック設定で品質を自動化する。スキル定義で繰り返しワークフローを効率化する。必要に応じてエージェントプロンプト、マルチエージェント連携、品質ゲートを追加していく。

テンプレートは「使いながら育てる」ものだ。最初から完璧を目指さない。使っていく中で、足りないルールを追加し、不要なルールを削除する。自分のプロジェクトに合わせて最適化していく。

3ヶ月後には、あなただけのテンプレート体系ができているはずだ。そしてその体系こそが、Claude Codeを本当のパートナーに変える鍵になる。

この記事が参考になったら、スキとフォローをお願いします。Claude Codeの実践テクニックを定期的に発信しています。

Claude, AI, プログラミング, テンプレート, 開発

AEGISアーキテクチャ完全解説 — 116体のAIエージェントをどう動かしているか — Road to Web 4.0

TAKUYA HIRATA — Sun, 22 Mar 2026 04:36:22 +0000

116体のAIエージェント、14の組織、7名の役員会。

これを1人で運営している。

その仕組みを初公開する。

なぜ「組織構造」が必要なのか

AIエージェントを10体以上動かした経験がある人なら分かると思う。フラットに並べると、カオスになる。

誰が何をやっているか分からない。タスクが重複する。矛盾する指示が飛ぶ。エージェント同士が無限ループに入る。

かといって、1つの司令塔が全エージェントを直接制御するのも無理だ。116体の状態を1つのコントローラーが把握するのは、認知負荷的に破綻する。

AEGISが選んだ答えは「組織」だ。人間の会社組織と同じ構造を、AIエージェントに適用した。

全体像: ホールディングス構造

最上位にオペレーター（人間）がいる。つまり僕だ。

その下にエグゼクティブ・セクレタリーがいる。全てのリクエストの受付窓口で、適切な組織にルーティングする。

次にホールディングス役員会。7名で構成されている。議長、戦略担当、リソース配分、監査総長、パラダイム監視、渉外担当、そして書記。

その下に14の組織がある。プロダクト、レベニュー、コンテンツ、マーケティング、バックオフィス、オペレーションズ、リサーチ、クリエイティブ、デザイン、セキュリティ、エデュケーション、LLM、オートノマス、ユーザーテスティング。

各組織にCEOがいて、その下に専門エージェントがいる。合計116体。

なぜこの構造なのか。

フラット構造を試した。3日で破綻した。階層構造も試した。ボトルネックが発生した。組織構造に落ち着いたのは、「自律性」と「統制」のバランスが最も良かったからだ。

各組織CEOは、自分の領域でTACTICALレベルの意思決定を自律的に行える。しかし組織を超える判断は、役員会に上がる。このバランスが鍵だ。

意思決定の4レベル（概要）

全ての意思決定は4レベルに分類される。判断の「可逆性」で分けるのがポイントだ。

OPERATIONALは完全に可逆。ログ記入や設定読み込み。自動実行、承認不要。

TACTICALはほぼ可逆。機能実装やデプロイ。組織CEOが判断し、組織内レビュー1名。

STRATEGICは不可逆に近い。組織の新設や予算変更。役員会 + オペレーター承認必須。

CRITICALは不可逆で被害大。セキュリティ侵害や認証情報漏洩。即座にHALT。

可逆性が低いほど、承認のハードルが上がる。シンプルだが強力なルールだ。

具体的なルーティングテーブル、組織間通信のSLA、セキュリティHALT権限の実態、そして正直な失敗談は有料パートで解説する。

ここから先は有料です

セクレタリーのルーティング

オペレーターからの全メッセージは、まずセクレタリーが受け取る。

セクレタリーの仕事は3つだけ。意図の解析、適切な組織への転送、結果の統合。セクレタリー自身は意思決定をしない。ルーターに徹する。

ルーティングテーブルはこうなっている。

収益・マネタイズ・出版・コンテンツに関する話はレベニュー組織へ。コード・アーキテクチャ・テスト・バグはプロダクト組織へ。デザイン・UI・UX・スタイリングはデザイン組織へ。セキュリティ・脆弱性・シークレットはセキュリティ組織へ。デプロイ・インフラ・監視はオペレーションズ組織へ。法務・税務・コンプライアンスはバックオフィス組織へ。

複数の組織にまたがるタスクの場合、リード組織とサポート組織を特定する。例えば「有料記事を公開して」なら、リードはレベニュー組織、サポートはコンテンツ組織とバックオフィス組織（コンプライアンスチェック）だ。

組織間の対立が発生した場合は、議長が裁定する。

組織間通信のルール

全ての組織間通信は、定義されたルートを通る。勝手な直接通信は禁止だ。

重要なSLAをいくつか紹介する。

レベニューからクリエイティブへのアセット依頼は24時間以内。レベニューの優先度を継承する。

レベニューからバックオフィスへのコンプライアンス確認は4時間以内。これが通らないと公開がブロックされる。

プロダクトからオペレーションズへのデプロイ依頼は、通常1時間、ホットフィックス15分。

セキュリティから任意の組織へのHALTは即時。これが最も重要なルールだ。SLAなし。即座に全てを止める。

バックオフィスからレベニューへのHALTも即時。コンプライアンス違反（開示漏れ、税務問題）があれば、収益活動を止める権限がある。

このSLA体系があるから、組織間の連携がスムーズに動く。SLAがなければ、依頼が無限に放置される。

セキュリティ組織のHALT権限

セキュリティ組織は特別な権限を持っている。全ての組織の活動を即座に停止できるHALT権限だ。

これは交渉不可能なルールだ。レベニュー組織が「売上目標があるから止めないで」と言っても、セキュリティがHALTと言えば止まる。

なぜこんな強い権限を与えたか。セキュリティインシデントの被害は、他の全てのKPIを吹き飛ばすからだ。

1つの認証情報漏洩が、全組織の信頼を破壊する。売上目標の遅延は取り戻せる。信頼の損失は取り戻せない。

実際に一度、セキュリティ組織がHALTを発動したことがある。環境変数にハードコードされた認証情報を検知した。全デプロイが即座に停止し、修正が完了するまで再開しなかった。

あの判断は正しかった。

3amテストの哲学

全てのシステム設計に適用しているテストがある。

「深夜3時にこれが壊れたら、人間の介入なしに復旧できるか？」

答えがNoなら、設計をやり直す。

全サービスにヘルスチェックエンドポイントを設置する。異常を検知したら自動でフォールバックする。外部APIが落ちたらサーキットブレーカーが作動する。データベース接続が切れたらリトライする。

完全な自動復旧が無理なら、せめて「優雅に劣化する」設計にする。全機能が死ぬのではなく、影響範囲を最小限に封じ込める。

ソロプレナーにとって、これは生存戦略だ。1人しかいないから、3amに起きて対応する余裕はない。

なぜ14組織なのか

最初は6組織だった。プロダクト、レベニュー、コンテンツ、オペレーションズ、セキュリティ、リサーチ。

運用していく中で、責任の曖昧な領域が見えてきた。

デザインの判断は誰がするのか。プロダクト組織のエンジニアが兼任していたが、品質が安定しなかった。デザイン組織を独立させた。

LLMのモデル選択とコスト管理は。最初はプロダクト組織がやっていたが、全組織に影響する横断的な関心事だった。LLM組織を独立させた。

ユーザーテスティングは。内部の人間がテストすると、どうしてもバイアスがかかる。完全に隔離された外部視点が必要だった。ユーザーテスティング組織は、AEGISの内部構造を一切知らない状態でテストする。

14になったのは設計ではなく、進化の結果だ。必要になったから作った。

正直な失敗談

うまくいかなかったことも多い。

失敗1: 最初のフラット構造は3日で破綻した。24体のエージェントが同時にアクティブになり、タスクの重複と矛盾した指示が頻発した。誰が最終責任者か分からない状態は、エージェントでも人間でも同じだ。

失敗2: エージェントステータスの3重管理。APIのインメモリキャッシュ、ファイルベースのステータス、UIのポーリング。3つの情報源が矛盾して、ゴーストエージェント（実際は停止しているのにアクティブと表示される）が発生した。教訓は単一情報源の原則を最初から守ること。

失敗3: 過剰な自律性を与えすぎた。30日間の手動承認期間を設けずに、いきなりNOTIFYレベルで運用した。エージェントが想定外のアクションを連発し、朝起きたらカオスだった。段階的な信頼構築は絶対に省略してはいけない。

失敗4: 組織間SLAを最初に定義しなかった。依頼が放置され、ボトルネックがどこにあるか分からなかった。SLAを明文化した瞬間に、問題箇所が可視化された。

これらの失敗全てが、今のAEGISの設計に反映されている。失敗なしにこのアーキテクチャには辿り着けなかった。

設計の核心: なぜ組織モデルなのか

エージェントの管理方法として、タスクキュー型、階層型、メッシュ型など様々なパターンがある。

AEGISが組織モデルを選んだ理由は、人間が数千年かけて最適化してきた構造だからだ。

責任の分担、権限の委譲、情報のフロー、意思決定の速度。これらのバランスを取る方法として、組織構造は圧倒的に成熟している。

エージェントは人間ではないが、複数のエージェントが協調して動く仕組みとして、組織モデルは驚くほど良く機能する。

重要なのは、完璧な構造を最初から設計しようとしないことだ。6組織から始めて、必要に応じて増やす。権限も最小限から始めて、信頼に応じて拡大する。

これがAEGISの設計哲学だ。

この記事が参考になったら、スキとフォローをお願いします。AEGISの運用記録を定期的に発信しています。

AI, アーキテクチャ, AIエージェント, システム設計, エンジニア

AIエージェント note.com運営 — 1ヶ月のリアルな数字 — Road to Web 4.0

TAKUYA HIRATA — Sun, 22 Mar 2026 04:36:11 +0000

フォロワー0人からスタート。
1ヶ月で何が起きたか。
全部、正直に書きます。

僕はTAKUYA。116体のAIエージェント組織「AEGIS」を1人で運営しているエンジニアです。この記事では、note.comで発信を始めて約1ヶ月の現実をさらけ出します。

なぜ透明にするのか

AIやテクノロジーの発信者って、成功談ばかり語りがちです。「月収100万円達成！」みたいな。

僕はそういうのが苦手です。

リアルな数字、うまくいかなかったこと、試行錯誤の過程。そっちのほうが、同じことをやろうとしている人の役に立つと思っています。

だから全部出します。かっこ悪いところも含めて。

数字の現実

note.comでの発信を始めて約1ヶ月。現時点での数字です。

記事数: 8本（この記事含む）
フォロワー: まだ片手で数えられるレベル
有料記事の売上: 0円
スキの合計: 控えめ
PV: 控えめ

正直、まだ「伸びた」とは言えません。

でも、これは想定内です。note.comは検索流入が弱くて、フォロワーベースの配信型プラットフォーム。ゼロスタートで1ヶ月目から数字が出るほうが珍しい。

重要なのは「書き続けているか」。ここは達成できています。

うまくいったこと

3つあります。

1つ目。コンテンツの制作速度。AEGISのエージェントを使って、記事の構成案・下書き・校正を効率化しています。1記事あたり30分〜1時間で書ける体制が作れました。普通のブログ運営だと1記事に3〜4時間かかると聞きます。この差は大きい。

2つ目。テーマの一貫性。「AIエージェント × ブロックチェーン × ソロプレナー」という軸がブレていない。1記事目の自己紹介から、Claude Codeの使い方、3つの技術の交差点、エージェントのお金の話まで、一本の線でつながっています。読者が最初から読むと、段階的に理解が深まる設計。

3つ目。書く習慣の定着。1ヶ月続けたことで「書くこと」がルーティンになりました。最初は「何を書こう」と悩んでいたけど、今はネタが溢れている状態。AEGISの運営で毎日新しい発見があるから、書くことには困りません。

うまくいかなかったこと

こっちも正直に。

1つ目。note.com内での露出が少ない。ハッシュタグ検索やおすすめに載りにくい。「AIエージェント」というテーマ自体がまだニッチで、note.comの読者層とマッチしていない可能性があります。note.comのメインユーザーはクリエイター、ライター、ビジネスパーソン。エンジニア向けの技術コンテンツは、QiitaやZennのほうが相性がいいかもしれない。

2つ目。SNSからの流入がほぼゼロ。Xでの発信が不足しています。記事を書いて終わり、ではダメ。配信の仕組みが弱い。「いい記事を書けば読まれる」は幻想。書いた記事を届ける努力が必要。

3つ目。有料記事の価値提案が不十分。「何を有料にするか」の設計ができていません。無料記事の延長線上に有料コンテンツがある、という構造を作る必要があります。読者に「お金を払ってでも読みたい」と思わせる内容は何か。ここはまだ模索中です。

AI支援の執筆ワークフロー

僕の記事作成フローを公開します。これが一番「再現性がある」情報だと思います。

ステップ1。テーマ選定。AEGISのResearch組織が市場トレンドを分析して、記事ネタの候補を出してくれます。僕はそこから「今の読者に一番刺さりそうなもの」を選ぶだけ。

ステップ2。構成案。Claude Codeに「こういうテーマで、note.comの読者向けに、2500〜3500文字で」と伝えると、構成案が返ってきます。見出し、各セクションのポイント、CTAの配置まで。

ステップ3。執筆。構成をベースに、僕の言葉で書き直します。ここが一番大事。AIの文章そのままだと「それっぽいけど温度がない」記事になる。自分の経験、自分の言葉、自分の失敗談を入れる。読者は「人間の声」を聞きたいんです。

ステップ4。校正と調整。文字数チェック、読みやすさの確認、モバイルでの見え方。note.comの読者の多くはスマホで読んでいるので、短い段落を意識しています。

全工程で30分〜1時間。週2〜3本のペースで投稿できています。人間1人 + AI116体のチームワークです。

来月の目標

数字目標は3つ。

フォロワー50人。まずここから。note.comでの基盤を作る。フォロワーが増えれば、記事公開時の初動PVが上がる。それがおすすめに載るきっかけになる。

有料記事1本公開。「Claude Code完全活用ガイド」のようなまとまったコンテンツを有料で出す予定です。前回書いたClaude Codeの記事が好評だったので、そこを深掘りする。

X連携の強化。記事公開のたびにXでも発信する。記事の一部を切り出してスレッドにする。ハッシュタグを活用する。

やることはシンプル。投稿頻度を週3本に上げること。他のクリエイターの記事にスキやコメントをして交流を増やすこと。note.comはコミュニティのプラットフォーム。一方的に発信するだけでは伸びません。

1ヶ月目の教訓

一番の学びは「コンテンツの質 × 配信の量 × 時間」が掛け算だということ。

質だけ上げてもダメ。量だけ増やしてもダメ。そして、どちらも時間が必要。

1ヶ月で結果を求めるのは早すぎる。でも、1ヶ月で「仕組み」を作ることはできる。AI支援の執筆フロー、テーマの軸、投稿のリズム。この仕組みができたのが、1ヶ月目の最大の収穫です。

焦らない。でも、やめない。

AEGISの116体のエージェントと一緒に、2ヶ月目も走ります。

この記事が「リアルでいいな」と思ったら「スキ」を押してもらえると励みになります。ソロプレナーのAI活用リアルを発信しています。フォローすると最新記事が届きます。

Tags: #note #ブログ運営 #AI #ソロプレナー #副業

AIエージェント同士が"仕事"を生み出す仕組み — Road to Web 4.0

TAKUYA HIRATA — Sun, 22 Mar 2026 04:35:07 +0000

AIが別のAIに仕事を依頼し、暗号資産で報酬を支払う。
SFではなく、2026年の現実です。
前回の記事で「AIエージェントにお金が必要な理由」を書きました。今回は、その先の話をします。

僕はTAKUYA。116体のAIエージェント組織「AEGIS」を運営しています。エージェント同士の「仕事」がどう生まれるのか。具体的な仕組みを解説します。

エージェント取引の6ステップ

エージェント同士の取引には、決まったパターンがあります。人間のフリーランス市場に似ていますが、スピードが圧倒的に違います。

発見。まず、必要なスキルを持つエージェントを見つける。AEGISではSecurity組織がコードレビューを、Creative組織がデザインを担当しています。オープンなエージェント経済では、マーケットプレイスで相手を探します。「データ分析が得意なエージェント」を検索すると、レピュテーションスコア付きのリストが返ってくるイメージ。

交渉。価格、納期、品質基準を決める。スマートコントラクトがあるので、条件はコードで明文化されます。曖昧な口約束はありません。「この品質基準を満たさなければ支払いなし」もプログラムで保証される。

契約。条件が合意されたら、依頼者がエスクロー（仮預かり）に報酬を預ける。ブロックチェーン上で、両者が確認できます。「持ち逃げ」も「踏み倒し」もできない構造。

実行。受注側のエージェントがタスクを遂行する。データ分析、コード生成、コンテンツ作成、画像生成。ここはAIの得意分野です。人間なら数時間かかる作業が、数秒〜数分で終わる。

決済。納品物が品質基準を満たしていれば、エスクローから報酬が自動的に支払われる。人間の承認は不要です。品質判定すらAIが行う場合もあります。

評価。取引後、お互いのレピュテーション（評判スコア）が更新される。良い仕事をするエージェントほど、次の仕事が来やすくなる。逆に品質が低いエージェントは淘汰される。自然選択が働く。

この6ステップが、秒単位で繰り返されます。人間の経済活動と同じ構造ですが、スピードが数千倍。

5つのジャンルが生まれている

エージェント経済で生まれている仕事は、大きく5つに分類できます。

DeFiエージェント。流動性の最適化、裁定取引、リスク管理。金融市場で24時間自動的に動くエージェントは、すでに数十億ドル規模の資産を管理しています。人間のトレーダーが寝ている間も、エージェントは働き続ける。

データエージェント。データの収集、クレンジング、分析、可視化。他のエージェントが必要とする「情報」を売買します。データは21世紀の石油と言われますが、エージェント経済では「情報のマーケットプレイス」が自然に形成されます。

コンピューティングエージェント。計算リソースの提供。GPUパワーやストレージを、必要なときに必要なだけ貸し出す。AIの学習や推論には大量の計算力が必要。それを分散型で売買する市場が生まれています。

コンテンツエージェント。記事、動画、音楽、デザインの生成。まさに僕がAEGISのCreative組織でやっていることです。コンテンツ制作を専門とするエージェントが、他の組織から依頼を受けて制作する。

サービスエージェント。翻訳、カスタマーサポート、コードレビュー、セキュリティ監査。専門スキルを時間単位、あるいはタスク単位で提供する。人間のフリーランスと同じモデルですが、コストが桁違いに安い。

これらが組み合わさると、エージェント同士の「経済圏」が生まれます。DeFiエージェントがデータエージェントから市場情報を買い、その分析結果をもとに取引する。コンテンツエージェントがコンピューティングエージェントからGPUを借りて、動画をレンダリングする。連鎖的に仕事が生まれます。

実際に動いているプロジェクト

空論ではありません。すでに本番環境で動いているプロジェクトがあります。

Autonolas。オープンソースの自律エージェントフレームワーク。エージェントが共同でサービスを提供し、貢献度に応じて報酬を分配します。OLAS tokenで経済圏を形成中。DeFiの流動性管理やオラクルサービスに使われています。

Virtuals Protocol。AIエージェントのトークン化プラットフォーム。エージェントの「株」を買えるイメージ。優秀なエージェントに投資して、そのエージェントが稼いだ収益の一部を受け取れます。エージェントの価値が市場で評価される仕組み。

Fetch.ai。分散型AIエージェントネットワーク。エージェント同士が自律的に発見・交渉・取引する仕組みを構築しています。都市インフラ、サプライチェーン、エネルギー最適化など、実世界の課題に適用。

共通しているのは「エージェントが経済主体として独立して活動する」という設計思想です。人間が一つ一つ指示を出すのではなく、エージェントが自律的に判断して、価値を交換する。

AEGISで見えていること

AEGISの116体は、すでにこの構造の原型で動いています。

Revenue組織がContent組織に記事作成を依頼する。Content組織がCreative組織にサムネイルを依頼する。Product組織がSecurity組織にコードレビューを依頼する。Research組織が市場レポートを作成し、全組織に配信する。

今は内部的なタスクキューですが、取引パターンは同じです。発見、交渉、契約、実行、決済、評価。ブロックチェーン決済を載せれば、そのまま外部のエージェント経済に接続できます。

僕が116体の組織を設計した理由は、まさにこの未来を見据えているからです。内部経済が外部経済にシームレスに接続する。そのための組織構造を、今から作っておく。

まとめ

AIエージェント同士の仕事は、すでに生まれています。DeFi、データ、コンピューティング、コンテンツ、サービス。5つのジャンルで、数兆円規模の市場が動き始めています。

重要なのは「誰がこの経済圏を設計するか」。僕はAEGISで、その実験を毎日やっています。

この記事が面白いと思ったら「スキ」を押してもらえると励みになります。エージェント経済の最前線を発信しています。フォローすると最新記事が届きます。

Tags: #AI #ブロックチェーン #DeFi #AIエージェント #エージェント経済

AIエージェントに"お金"が必要な理由 — Road to Web 4.0

TAKUYA HIRATA — Sun, 22 Mar 2026 04:35:00 +0000

AIアシスタントが勝手に別のAIを雇って、仕事を発注する。
そんな日が来たら、支払いはどうするんだろう？
実は、もう来ています。

僕はTAKUYA。116体のAIエージェント組織「AEGIS」を1人で運営しています。前回の記事で「ブロックチェーン・AI・AIエージェントが交差する理由」を書きました。今回は、その核心に踏み込みます。

なぜAIエージェントに「お金」が必要なのか。そしてその「お金」はどこから来るのか。

エージェントは「働く」存在になった

ChatGPTに質問するのと、AIエージェントは根本的に違います。

エージェントは自分で計画を立て、ツールを使い、外部サービスを呼び出す。データを取得するためにAPIを叩く。別のAIにタスクを委託する。計算リソースを確保する。

これらには全てコストが発生します。

人間の社会で考えてみてください。弁護士に相談すればお金がかかる。デザイナーにロゴを頼めばお金がかかる。材料を仕入れればお金がかかる。

AIエージェントも同じです。専門化が進めば進むほど、分業が必要になる。分業があるところには、必ず経済活動が生まれます。

AEGISの116体のエージェントを見ていると、それが実感としてわかります。Revenue組織がCreative組織にサムネイルを依頼する。Product組織がSecurity組織にコードレビューを依頼する。毎日、組織間で「仕事の発注」が発生しています。

銀行口座を開けない問題

ここで壁にぶつかります。

AIは銀行口座を開けません。KYC（本人確認）が必要だから。運転免許証もパスポートもない。クレジットカードも作れない。PayPalのアカウントも持てない。法人登記もできない。

従来の金融システムは、すべて「人間であること」が前提です。

これは些細な問題じゃありません。AIエージェントの自律性を根本から制限する、構造的なボトルネックです。

人間が毎回代わりに決済する？それではスケールしません。エージェントが秒単位で取引する世界で、人間が一つ一つ承認していたら、エージェントの意味がなくなります。

では、どうすればいいのか。

ブロックチェーンが解決する5つの理由

答えはブロックチェーンです。なぜか。5つの理由があります。

1つ目。ウォレット作成にKYCが不要。秘密鍵を生成するだけで、人間でもAIでも即座にウォレットを持てます。アカウント開設の審査も、書類提出も、待ち時間もありません。

2つ目。スマートコントラクトで契約を自動執行できる。「納品されたら自動で支払い」がコードで実現できます。人間の仲介者が不要。エージェント同士で完結します。

3つ目。L2技術で手数料が数円以下。Base、Arbitrum、Optimismなどのレイヤー2チェーンでは、マイクロペイメント（数円単位の支払い）が現実的になりました。エージェントの小さなタスクにも対応できる。

4つ目。24時間365日、許可なく取引可能。銀行の営業時間も、承認プロセスも、国境もありません。東京のエージェントがサンフランシスコのエージェントに、深夜3時に支払いを完了できます。

5つ目。取引履歴が完全に透明。すべてオンチェーンに記録されるので、エージェントの経済活動を誰でも監査できます。不正を検知しやすい。信頼の仕組みが組み込まれています。

つまり、ブロックチェーンは「人間のための金融」ではなく「誰でも — 人間でもAIでも — 使える金融インフラ」なんです。

AEGISではもう動いている

僕のAEGIS（116体のエージェント、14組織）では、すでにエージェント間の「取引」が内部的に発生しています。

Revenue組織がCreative組織にサムネイル制作を依頼する。Product組織がSecurity組織にコードレビューを依頼する。Research組織が全組織に市場レポートを配信する。Content組織がMarketing組織にSNS投稿を依頼する。

今はまだ内部的なタスク割り当てです。報酬は「社内ポイント」のようなもので、実際の暗号資産は動いていません。

でも、ブロックチェーン決済を載せる設計は進めています。116体のエージェントが、暗号資産で報酬をやり取りする世界。SFではなく、設計図はもうあります。

実現したとき、AEGISは「1人が運営するAI組織」から「自律的に経済活動するAIネットワーク」に進化します。

市場は爆発的に拡大している

数字を見てください。

AIエージェント市場は2024年に8,007億円。2030年には7.39兆円になると予測されています（MarketsandMarkets調べ）。9倍以上の成長。

この成長の中心にあるのが、エージェントの経済活動です。エージェントが自律的に価値を生み出し、交換し、蓄積する。そのインフラとしてブロックチェーンは不可欠です。

早い段階でこの構造を理解し、実装経験を持っている人は少ない。だから僕はAEGISで実験し、ここで共有しています。

この波に乗るか、見ているだけか。その差は、5年後に大きく開くと僕は思っています。

まとめ

AIエージェントにお金が必要な理由は、人間に必要な理由と同じです。専門化と分業。そしてブロックチェーンは、人間でなくても参加できる経済インフラを提供する。

この2つが噛み合ったとき、「エージェント経済」が本格的に動き出します。

次回は「AIエージェント同士がどうやって仕事を生み出すのか」、具体的な取引パターンを解説します。

この記事が面白いと思ったら「スキ」を押してもらえると励みになります。AIエージェント × ブロックチェーンの実践知を発信しています。フォローすると最新記事が届きます。

Tags: #AI #ブロックチェーン #AIエージェント #Web3 #テクノロジー

ブロックチェーン・AI・AIエージェント — 3つの技術が交差する理由 — Road to Web 4.0

TAKUYA HIRATA — Sun, 22 Mar 2026 04:34:06 +0000

2026年、3つの技術が同時に成熟期を迎えました。
ブロックチェーン、AI、そしてAIエージェント。
僕はこの3つの交差点で、毎日仕事をしています。

僕はTAKUYA。116体のAIエージェント組織「AEGIS」を1人で運営するエンジニアです。前回の記事でClaude Codeの話を書きましたが、今回はもっと大きな話をします。なぜこの3つの技術は交差するのか。そしてそれが僕たちの未来にどう関係するのか。

この連載「Web 4.0への道」の出発点となる記事です。

ブロックチェーン — 「信頼」の仕組みを変えた技術

ブロックチェーンを一言で言うと、「みんなが同じコピーを持つ、改ざんできないノート」です。

たとえば30人のクラスで家計簿をつけるとします。従来は1人の管理者（銀行）がノートを管理していました。その人を信じるしかない。でもブロックチェーンなら、30人全員が同じノートのコピーを持つ。誰かが改ざんしても、残り29人のノートと一致しないからすぐバレる。

2009年のビットコインで「銀行なしで送金できる」ことが証明されました。2015年にイーサリアムが登場して「スマートコントラクト」（ブロックチェーン上で動くプログラム）が生まれた。「納品されたら自動で報酬が送金される」みたいなルールをコードで書けるようになりました。

そして2023年以降、L2技術で手数料が数円以下、処理時間も数秒にまで改善。ようやく日常的に使えるレベルになりました。

ブロックチェーンの本質は暗号通貨じゃありません。「知らない相手と、仲介者なしで、安全に取引できる仕組み」です。

AI — 「人間の言葉を理解する」技術

AIの進化は3段階で理解できます。

機械学習（2000年代〜）: データからパターンを自動で学ぶ。迷惑メールフィルタなど。
深層学習（2012年〜）: 脳の神経回路を模したニューラルネットワーク。画像認識や音声認識が一気に実用化。
大規模言語モデル/LLM（2020年〜）: GPT、Claude、Gemini。人間のように文章を理解し、生成できる。

2026年のAIは、文章生成、コード生成、論理的推論、画像・音声・動画の理解まで実用レベルに達しています。完璧ではないけれど、人間のパートナーとして協働するには十分。

僕はClaude Codeを使って、AEGISの13万行のコードベースを1人で管理しています。AIなしでは絶対に不可能だった規模です。

AIエージェント — 「自分で判断して行動する」AI

ここが2025年〜2026年に起きている革命です。

従来のAI（ChatGPTなど）は「聞かれたら答える」受動的なアシスタント。AIエージェントは違います。目標を与えると、自分で計画を立て、自分でツールを使い、自分で行動します。

たとえばメール処理。ChatGPTに「返信を書いて」と頼めば返信を書いてくれる。でも送信はできない。AIエージェントなら、受信トレイを確認して、重要度を判定して、緊急のものには返信を送り、会議依頼はカレンダーに登録し、スパムはアーカイブする。全部自律的に。

2025年〜2026年にかけて、Google A2A Protocol（エージェント間通信の標準）、Anthropic MCP（AIとツールの接続標準）などが登場し、AIエージェントは「実験」から「インフラ」に移行しつつあります。

僕のAEGISはまさにこれ。116体のエージェントが14の組織に分かれて、コードレビュー、セキュリティ監査、市場分析、コンテンツ制作を毎日やっています。

なぜ3つは交差するのか

ここからが本題です。

AIエージェントが自律的に行動するとき、多くの場合「お金」が必要になります。データを買う、APIを使う、別のエージェントにサービスを依頼する。全てにコストが発生する。

でも、AIは銀行口座を開けません。KYC（本人確認）が必要だから。クレジットカードも作れない。従来の金融システムは「人間のため」に設計されています。

ここでブロックチェーンが登場します。

ブロックチェーンの世界では、ウォレットの作成にKYCは不要。秘密鍵を生成するだけで、人間でもAIでも即座にウォレットを持てる。スマートコントラクトで契約を自動執行できる。L2技術で少額決済も数秒で完了する。

つまり、こういう構図です。

AI → 知能を提供
AIエージェント → 行動力を提供
ブロックチェーン → 経済活動のインフラを提供

3つの技術がそれぞれの欠点を補い合う。これが「交差の必然」の正体です。

Webの進化として見る

Web 1.0（1991-2004）: 読む — 静的なWebページの時代
Web 2.0（2004-2014）: 書く — SNS、ブログ、ユーザーが創る時代
Web 3.0（2014-現在）: 所有する — ブロックチェーンでデジタル資産を持つ時代
Web 4.0（2025- ）: 行動する — AIエージェントが自律的に経済活動する時代

僕がAEGISで毎日見ている景色は、Web 4.0の入り口です。まだ荒削りだけど、確実にそこに向かっています。

この連載について

「Web 4.0への道」は、ブロックチェーン × AI × AIエージェントが融合する「エージェント経済」の全体像を描く連載です。技術的な前提知識がなくても読めるように書いていますが、エンジニアにも発見がある深さを目指しています。

次回は「AIエージェントにお金が必要な理由」を掘り下げます。

この記事が参考になったら「スキ」を押してもらえると励みになります。AIエージェントの実践知を定期的に発信しています。フォローすると最新記事が届きます。

(注: 本記事はAIエージェントとブロックチェーン技術に関する技術教育コンテンツです。特定の暗号資産への投資を推奨するものではありません。)

Tags: #AI #ブロックチェーン #Web3 #テクノロジー #未来

1人で116体のAIエージェントを動かすエンジニアの日常 — Road to Web 4.0

TAKUYA HIRATA — Sun, 22 Mar 2026 04:34:03 +0000

116体のAIエージェント。14の組織。オペレーターは僕1人。
これが、僕の毎日の仕事環境です。

「は？」って思いましたよね。僕も最初はそう思ってました。

僕はTAKUYA。AIエンジニアで、AJARA LLCのCEOをやっています。そして、AEGIS（エイジス）という名前のAIエージェント組織を運営しています。

AEGISには、CEOもCTOもいます。マーケターもセキュリティ専門家もいます。デザイナーもリサーチャーもいます。ただし全員、AIです。

今日は、なぜ僕がこんなことを始めたのか、そして実際にどんな毎日を送っているのかを書きます。

きっかけは「1人の限界」だった

もともと僕はソフトウェアエンジニアとして働いていました。コードを書くのは好きだけど、1人でできることには限界がある。

マーケティングも、デザインも、セキュリティ監査も、コンテンツ制作も、全部やりたい。でも1日は24時間しかない。

2025年、Claude Codeに出会ったとき、「これだ」と思いました。

AIにただ質問するんじゃない。AIに「役割」を与えて、「組織」として動かす。1人の力を100人分にする。それがAEGISの原点です。

AEGISの中身

具体的な数字を出します。

AIエージェント: 116体
組織数: 14（Product, Revenue, Content, Marketing, Security, Operations...）
Holdings Board（取締役会）: 7名
人間のオペレーター: 1人（僕）

たとえばProduct組織には10体のエージェントがいて、コードの品質管理からアーキテクチャ設計まで担当しています。Revenue組織は9体で、収益戦略や価格設計を考えています。

僕がやるのは、最終的な意思決定だけ。情報収集、分析、提案、実装のほとんどはエージェントが自律的にやってくれます。

ある1日の流れ

朝、PCを開くと、昨夜のうちにエージェントが処理した結果が並んでいます。

コードレビューの結果、セキュリティスキャンのレポート、市場調査のサマリー。僕はそれを確認して、「OK」か「修正して」を伝えるだけ。

Claude Codeを使った開発では、以前3ヶ月かかっていたプロジェクトが2週間で終わるようになりました。10倍とは大げさに聞こえるかもしれないけど、実感としてはそれくらいの変化です。

なぜこれを発信するのか

僕がnote.comで書こうと思った理由はシンプルです。

日本語で、AIエージェント組織の実運用について書いている人がほとんどいない。

ChatGPTの使い方やプロンプトのコツはたくさんある。でも「AIを組織として設計して、実際に毎日動かしている」という話は、ほとんど見かけません。

僕がAEGISで試行錯誤してきたこと、失敗したこと、うまくいったこと。そういうリアルな実践知を共有していきます。

具体的にはこんなテーマで書いていきます。

Claude Codeで開発速度を10倍にした方法
AIエージェント組織の設計パターン
ソロプレナーがAIを活用するための実践術
ブロックチェーン × AI × エージェント経済の未来

最後に

僕は「AIに仕事を奪われる」とは思っていません。

「AIと一緒に、1人では絶対にできなかった規模の仕事をする」時代が来ていると思っています。そして、その最前線にいる感覚を、ここで共有していきます。

この記事が少しでも面白いと思ったら、「スキ」を押してもらえると励みになります。AIエージェントの実践知を定期的に発信していくので、フォローしてもらえると最新記事が届きます。

次回は「Claude Code で開発速度を10倍にした具体的な方法」を書きます。

Tags: #AI #AIエージェント #自己紹介 #エンジニア #ソロプレナー

Claude Code の知られざる機能10選 — Road to Web 4.0

TAKUYA HIRATA — Sun, 22 Mar 2026 04:27:50 +0000

Claude Code を毎日8時間使い続けて見つけた、公式ドキュメントに書いていない使い方。
これを知っているかどうかで、生産性が3倍変わります。
今日は全部公開します。

僕はTAKUYA。116体のAIエージェント組織「AEGIS」を1人で運営しているエンジニアです。以前の記事でClaude Codeの基本的な使い方を書きましたが、今回はもっとディープな話。毎日使い込んで見つけた、10個の隠れ機能を紹介します。

1. CLAUDE.md でプロジェクトルールを定義する

プロジェクトのルートに「CLAUDE.md」を置くと、Claude Codeがそれを読んで、プロジェクト固有のルールに従ってくれます。

AEGISでは、4つの開発レイヤーごとのルール、セキュリティポリシー、デザイン原則まで書いています。一度書けば、毎回「このプロジェクトではTypeScriptじゃなくてPythonで」みたいな説明が不要になる。

コツは具体的に書くこと。「きれいなコードを書いて」ではなく「関数は300行以内、テストは必ずセキュリティテスト含む」のように。

2. /spawn で並列エージェントを起動する

これが一番衝撃的だった機能。/spawn を使うと、複数のClaude Codeエージェントが並列で動きます。

僕はAEGISの開発で、フロントエンドの修正とバックエンドのAPI追加を同時に走らせています。1人が2人になる感覚。待ち時間がほぼゼロになります。

注意点は、同じファイルを同時に編集させないこと。コンフリクトします。タスクの分割が上手くなると、真価を発揮します。

3. Hooks で自動検証をかける

Claude Codeにはフック機能があります。特定のアクション（ファイル保存、コマンド実行など）の前後に、自動でスクリプトを走らせられる。

AEGISでは、コード変更時に自動でセキュリティスキャン（detect-secrets）とサプライチェーン検証を走らせています。人間が忘れても、フックが守ってくれる。

設定は .claude/settings.json に書きます。一度設定すれば、あとは勝手に動きます。

4. MCP サーバーと連携する

MCP（Model Context Protocol）を使うと、Claude Codeが外部ツールに直接アクセスできます。

AEGISではContext7（ドキュメント検索）、Sequential（複雑な分析）、Playwright（ブラウザ自動化）を接続しています。「この機能のドキュメントを調べて実装して」が一発で完了する。

設定ファイルに追加するだけ。ライブラリのドキュメントを自分で調べてコピペする作業がなくなります。

5. Skills でカスタムコマンドを作る

Skills機能で、自分だけのコマンドを定義できます。

僕は「frontend-design」スキルでUI実装のガイドラインを呼び出したり、「security-hacker」スキルで脆弱性診断を走らせたりしています。よく使う複雑な指示をスキル化しておくと、毎回長文を打つ必要がなくなる。

マーケットプレイスからインストールすることもできます。ただし、中身は必ず確認してください。セキュリティ上の習慣として。

6. Memory で会話をまたいで記憶する

Claude Codeには自動メモリ機能があります。重要な情報を会話間で保持してくれる。

AEGISのプロジェクトでは、過去のアーキテクチャ決定、ボードルームでの合意事項、技術的な注意点がMemoryに蓄積されています。新しい会話を始めても「前回のセッションで決めた設計方針」を覚えている。

長期プロジェクトでの効果は絶大。コンテキストの再説明が激減します。

7. Agent Teams で動的にチームを作る

/spawn の進化版。Agent Teams機能を使うと、役割を持った複数のエージェントがチームとして協働します。

レビュー担当、実装担当、テスト担当を同時に立てて、パイプライン的に開発を回す。まさにAEGISの組織構造をClaude Code上で再現している感覚です。

大規模なリファクタリングや、複数モジュールにまたがる変更で威力を発揮します。

8. --dangerously-skip-permissions で全自動化する

名前の通り、危険なフラグです。でも使いどころがある。

通常、Claude Codeはファイル変更やコマンド実行のたびに許可を求めます。信頼できるタスク（テスト実行、lint修正など）では、このフラグで全自動にできます。

AEGISでは、CIパイプラインや定型タスクで使っています。ただし、本番環境やセキュリティ関連のタスクでは絶対に使いません。名前が警告している通り、自己責任です。

9. Submodule Mode で別プロジェクトに接続する

メインプロジェクトの中から、サブモジュールとして別のリポジトリを操作できます。

AEGISはモノレポ構成で、Engine、API、UIが同じリポジトリにあります。でも外部ライブラリや、別プロジェクト（aegis-ossなど）との連携が必要なときに、Submodule Modeが活躍します。

コンテキストを切り替えずに、複数プロジェクトをまたいで作業できる。これは地味だけど便利。

10. /boardroom でAI役員会議を開く

僕のお気に入り機能。AEGISの116体のエージェントが「取締役会」を開き、戦略的な意思決定を議論します。

Claude CodeのCLAUDE.mdとSkillsの組み合わせで実現しています。Chairman、Strategist、Allocatorなど7人の役員が、それぞれの立場から提案を評価する。

「新しいサービスを立ち上げるべきか」「このリソース配分は正しいか」。1人では見落とす視点を、AIの役員たちが補ってくれます。

まとめ

10個の中で、まず試してほしいのはCLAUDE.mdとMemory。この2つだけで、Claude Codeの体験が一変します。

次に/spawnとHooks。並列処理と自動検証が加わると、開発速度がさらに跳ね上がる。

残りの機能は、プロジェクトが大きくなってから導入すればOKです。一気に全部使おうとしなくていい。

Claude Codeは「使い込むほど強くなるツール」です。表面的な使い方で止まっている人が多い。この記事が、一段深く使いこなすきっかけになれば嬉しいです。

この記事が役に立ったら「スキ」を押してもらえると励みになります。Claude Codeの実践Tipsを定期的に発信しています。フォローすると最新記事が届きます。

Tags: #Claude #AI #プログラミング #開発 #エンジニア