PR

〖導入編〗Palo Alto Research Labとは?AIエージェントとAAA CRMの構想を整理

Palo Alto Research Lab、AIエージェント、AAA CRMの構想を紹介する記事のアイキャッチ。リコ社長と複数のAIエージェント、CRMをイメージした青いデジタル基盤を描いた画像。 AI Agents
Palo Alto Research Labが示す、AIエージェント、CRM、複数AIの連携構想を整理する導入記事のアイキャッチ。

暗い背景に柔らかな光の粒が漂うデザイン。中央に「リコ社長の構造都市ブログ」のタイトルがネオン風フォントで表示され、下部に by President RIKO とブログのURLが記載されているヘッダー画像。

本記事は、Palo Alto Research Labが公開しているAAA GitBookのうち、「From 2015 to 2025」「History of AI CRM “C(H+A)RM” creation」「LLMs vs AI Agents」「Key Differences Between LLMs and AI Agents」「Launchpad for AI-Agents」「Swarm Orchestration: AI Agents at Scale」などをもとに、外部の観察者として要点を整理した解説記事です。

🕒 最終更新日:2026年6月20日

📘 本記事の立場(重要)
・本稿は、Palo Alto Research Labが示すAIエージェント、CRM、AI Agents LaunchPad、Swarm Orchestrationの構想と、その背景にある考え方を一般読者向けに整理することを目的としています。
・記載内容は公開資料に基づく要約・再構成であり、投資判断、金融取引、特定サービスや技術の利用・導入を推奨するものではありません。
・記事内には、公開資料の要約に加え、構想と実装を分けて見る視点、人による確認や責任のあり方に関する筆者の解釈が含まれます。必要に応じて、一次資料であるAAA GitBook原文および最新の公式公開情報をご確認ください。
・本記事では、GitBook内で扱われるトークン、資金調達、投資家向け機能などは対象とせず、AIエージェント、CRM、AI Agents LaunchPad、Swarm Orchestrationに関する記述を中心に扱います。

AIエージェント。CRM。Web3。LaunchPad。

新しい言葉が並ぶと、それだけで少し遠い話に見えることがあります。

一つずつ意味を調べれば、言葉そのものは理解できるかもしれません。けれど、言葉を覚えることと、その仕組みが何を目指しているのかをつかむことは、同じではないように思います。

私も最初は、AIエージェントという言葉を、便利なAIがさらに賢くなったものくらいに受け取っていました。

しかし資料を読み進めると、そこでは単に文章を作ったり、質問に答えたりするAIだけが語られているわけではありませんでした。
人と人をつなぐこと。散らばった情報を整理すること。役割の異なるAIが協力し、仕事の流れを支えること。

そうした仕組みを、Web3の世界でどう形にしていくのか。そのための構想として、Palo Alto Research Lab、AAA C(H+A)RM、AI Agents LaunchPadという言葉が置かれているように見えます。

では、この構想は、どこから見ればよいのでしょうか。

新しい仕組みを見る時、私はまず「何ができると書かれているか」よりも、「なぜ、それが必要になったのか」を見るようにしています。

どのような課題があり、何を整理しようとしているのか。人が担ってきた作業のどこにAIを置き、どこに人の確認を残そうとしているのか。

そこを見ないまま、便利さや将来性だけを先に受け取ると、仕組みの輪郭はかえって見えにくくなるからです。

この記事では、Palo Alto Research Labが公開しているAAA GitBookをもとに、AIエージェント、CRM、LaunchPadがどのようにつながっているのかを、できるだけ順番に整理していきます。

これは、投資判断や利用を勧めるための記事ではありません。
公開資料に何が示されているのか。そこからどのような構想が読み取れるのか。そして、構想と実際の運用を分けて見るためには何が必要なのか。

その点を、外部から資料を読む一人として考えていきたいと思います。


リコ社長が、人物ネットワーク、CRMによる情報整理、AIエージェントの活用、複数AIの連携という流れを説明する図解。
人のつながりを起点に、CRMで情報を整理し、AIエージェントの活用と連携へ進む構想を示したイメージ。

🤔 Palo Alto Research Labは、どのような構想から始まったのでしょうか

Palo Alto Research Labという名前を見ると、最初からAIエージェントの研究やWeb3の仕組みをつくるために始まった組織のように感じるかもしれません。

けれど、公開されている資料を読むと、その出発点はもう少し前にあります。

公式資料では、2015年に始まったPlatinum Engineeringが、分散型台帳やブロックチェーンに関する開発・支援を行ってきたことが説明されています。

その後、プロジェクトをつくる人、資金を出す人、技術を持つ人の間をつなぐ仕事が増える中で、必要になったのが、複数の場所に散らばる情報ややり取りを整理する仕組みでした。

Telegram、Discord、X、メールなど、連絡の場が増えるほど、人の記憶や個別のやり取りだけで全体を追うことは難しくなります。

誰が何をつくっているのか。どのような技術を持っているのか。どのような相手と話しているのか。

そうした情報を整理し、人と人をつなぐための仕組みとして、CRMが使われるようになったと資料では説明されています。

2021年には、Platinum Engineeringのチームの一部が、シリコンバレーのパロアルトへ活動の拠点を移し、現地の投資家や開発者、起業家との関係を広げていったとされています。
その流れの中で、資料では、名称変更を経ながら後にPalo Alto AI Research Lab/Palo Alto AI Web3 Research Labとされるコミュニティが形づくられていったと説明されています。

つまり、この構想は、最初から「AIに仕事を任せる未来」だけを描いて始まったわけではありません。

人を探すこと。情報を整理すること。適した人どうしを結びつけること。

そうした現実の手間をどう支えるか。その問いから始まり、CRM、AI、そしてAIエージェントの構想へと広がっていったように見えます。

では、そのCRMは、なぜAIエージェントを扱う仕組みへ発展していったのでしょうか。

※本章は、AAA GitBook「1.1 From 2015 to 2025」をもとに構成しています。本文中の沿革や活動内容は、同資料に記載された運営側の説明を整理したものです。
出典:AAA GitBook「1.1 From 2015 to 2025


🧑‍💼CRMは、なぜAIエージェントの仕組みへ発展したのでしょうか

人と人をつなぐ仕事では、情報そのものよりも、情報が散らばっていることの方が問題になる場合があります。

ある人はTelegramにいる。別の人はDiscordにいる。Xで話している人もいれば、メールやSlackだけで連絡を取る人もいます。

やり取りの場所が増えるほど、誰と何を話したのか。どのプロジェクトが今、どの段階にあるのか。誰と誰をつなぐべきなのか。その全体を、一人の記憶だけで追うことは難しくなっていきます。

公開資料では、こうした課題に対応するため、複数の連絡手段を横断して扱うCRMを整えていったと説明されています。
CRMというと、顧客情報を管理するための仕組みを思い浮かべるかもしれません。

しかし、この場合に扱おうとしていたのは、名前や連絡先だけではなかったようです。

創業者の活動。開発者の技術。投資家の関心。プロジェクトの進み方。コミュニティの中で生まれる会話。

それぞれを切り離して見るのではなく、関係の流れとして整理する。そのための土台として、CRMが使われていたと考えると分かりやすいでしょう。

ただ、人が扱う情報には限りがあります。

新しい話題が生まれ、連絡先が増え、確認すべき情報が積み重なるほど、すべてを同じ速度で追い続けることは難しくなります。

そこで資料では、AIを活用したスカウトエージェントを取り入れ、人だけでなくAIにも情報の探索や整理を担わせる方向へ進んだと説明されています。

ここで大切なのは、AIが人に代わってすべてを決める、という話ではありません。

多くの情報の中から、確認すべき候補を見つける。変化を見落としにくくする。人が次に何を見るべきかを考えるための材料を整える。

AIエージェントは、まずそのような役割から考える方が自然ではないでしょうか。
CRMは、連絡先を記録する仕組みから、関係や情報の流れを扱う仕組みへ広がっていきました。

そして、その流れを支えるためにAIが加わり、さらに役割の異なるAIエージェントが連携する構想へと広がっていった。
Palo Alto Research Labの資料では、そのような変化が、AAA C(H+A)RMへつながる一つの道筋として示されています。
では、AIエージェントは、具体的にどのような役割を担うものとして考えられているのでしょうか。

※本章は、AAA GitBook「1.3. History of AI CRM “C(H+A)RM” creation:」をもとに構成しています。本文中のCRMの発展やAIエージェントに関する説明は、同資料に記載された運営側の説明を整理したものです。
出典:AAA GitBook「1.3. History of AI CRM “C(H+A)RM” creation:


🤖 AIエージェントは、どのような役割を担うのでしょうか

AIエージェントという言葉を聞くと、人の代わりに何でも判断し、仕事を終わらせてくれる仕組みを想像するかもしれません。
けれど、資料を読む限り、AIエージェントの役割は、そこまで単純なものではないようです。

この資料で比較されているLLMは、質問に答えたり、文章をつくったりする場面で役立つ仕組みとして説明されています。

一方でAIエージェントは、ある目的に向けて情報を集め、決められた手順に沿って作業し、必要に応じて外部の仕組みや人へ結果を渡す存在として考えられています。

たとえば、日々増える情報の中から、確認が必要な話題を探す。複数の資料を整理し、次に見るべき候補をまとめる。決められた形式で文章や報告の下書きを用意する。

こうした役割であれば、AIは人の仕事を奪うというより、人が考える前の準備や、繰り返し発生する作業を支える存在になります。

ただし、AIが情報を集めたからといって、その内容が正しいとは限りません。

AIが候補を示したからといって、その判断をそのまま採用してよいとも限りません。

使う情報は適切か。前提が変わっていないか。相手に影響する判断ではないか。
その確認は、最後まで人が担う必要があります。

私は、AIエージェントの価値は「人の代わりに結論を出すこと」よりも、人が見落としやすい情報を整え、次の判断をしやすくすることにあるように思います。

  • 人が目的を決める。
  • AIが情報や作業を整理する。
  • 人が結果を確かめ、必要なら止める。

この役割分担があって初めて、AIエージェントは便利なだけでなく、使う側にとって扱いやすい仕組みになるのではないでしょうか。

では、こうしたAIエージェントを一つずつ使うだけでなく、複数の役割に分けて連携させると、何が変わるのでしょうか。

※本章は、AAA GitBook「2.1 LLMs vs AI Agents」「2.2 Key Differences Between LLMs and AI Agents」および関連するプラットフォーム説明を参照し、AIエージェントの一般的な役割を整理したものです。
なお、「どこまでAIに任せ、どこで人が確認するべきか」という部分は、公開資料の内容を踏まえた筆者の考察です。AIによる出力や提案の正確性、妥当性、最終的な責任を保証するものではありません。
出典:AAA GitBook「2.1 LLMs vs AI Agents」「2.2 Key Differences Between LLMs and AI Agents


🤝 AI Agents LaunchPadとOrchestration Layerは、何を目指しているのでしょうか

一つのAIエージェントに、すべての仕事を任せる。
言葉だけを聞くと、便利そうに見えるかもしれません。

けれど実際の仕事には、情報を探す役割、内容を整理する役割、文章をつくる役割、確認する役割があります。人間の組織でも、一人ですべてを担うより、役割を分けた方が流れが整うことがあります。

AAA GitBookで示されているAI Agents LaunchPadとOrchestration Layerも、そうした役割分担をAIエージェントの世界で考えようとする構想に見えます。

🛠️ AI Agents LaunchPadは、AIエージェントを形にするための入口です

AI Agents LaunchPadは、資料上では、AIエージェントをつくり、必要な役割を持たせ、動かしていくための入口として位置づけられています。

たとえば、情報を集めるAI。調査を補助するAI。発信の下書きを整えるAI。開発作業を支えるAI。

同じAIエージェントという言葉でも、担わせたい仕事によって必要な設定や情報は変わります。

そのため、LaunchPadは、単にAIを呼び出す場所というよりも、目的に合わせたAIエージェントを組み立てるための場として考えると分かりやすいでしょう。

ただ、AIエージェントを作れることと、すぐに安心して任せられることは別です。
何をさせるのか。どの情報に触れさせるのか。どの結果を人が確認するのか。

入口が簡単になるほど、使う側には、その設計を考える責任も残ります。

リコ社長が、AI Agents LaunchPadで役割別のAIを配置し、複数のAIが連携しながら進み、最後は人が確認・停止できる流れを説明する図解。
人が目的を決め、LaunchPadでAIエージェントを配置し、複数のAIが分担・連携しながら進め、最後は人が確認する構想を示したイメージ。

👥 Orchestration Layerは、複数のAIに役割を分ける考え方です

一つのAIエージェントだけでは、できることに限りがあります。

そこで資料では、複数のAIエージェントが、それぞれ異なる役割を持ちながら連携する仕組みとして、Swarm Orchestrationが説明されています。

  • あるAIが情報を集める。
  • 別のAIが内容を整理する。
  • さらに別のAIが、決められた条件に沿って作業を進める。

このように役割を分ければ、一つのAIにすべてを背負わせるよりも、作業の流れを細かく設計できます。

資料では、AIエージェント同士が仕事を割り振り、状況に応じて連携する仕組みが構想として示されています。
人の組織でいえば、担当者がそれぞれの仕事を受け持ち、必要な時に情報を渡し合う形に少し似ています。

※資料では、人による常時の指示を前提としない自律的なAIエージェント群として説明されています。一方で本記事では、その構想が実際の利用に移される場合には、人による確認、停止手段、説明責任が重要になるという観点から考えます。

👀 自動化が進むほど、流れを見えるようにする必要があります

複数のAIが動く仕組みには、作業を速く進められる可能性があります。
一方で、どのAIが何をしたのか。どの情報をもとに動いたのか。途中で問題が起きた時、どこで止めるのか。

こうした点が見えなければ、仕組みが複雑になるほど、使う人は判断しにくくなります。

私は、AIエージェントの連携で大切なのは、どこまで自動化できるかだけではないと思います。

  • どの仕事を任せるのか。
  • どの仕事は人が確認するのか。
  • 問題が起きた時、誰が止め、誰が説明するのか。

その流れまで考えられて初めて、AIエージェントは便利な仕組みとしてではなく、使う側が扱える仕組みになるのではないでしょうか。
では、このような構想を読む時、私たちは何を分けて見ればよいのでしょうか。

※本章は、AAA GitBook「1.6. Launchpad for AI-Agents」および「2.4. Swarm Orchestration: AI Agents at Scale」をもとに構成しています。AI Agents LaunchPadをAIエージェントの作成・活用に向けた場として、Orchestration Layerを複数のAIエージェントが役割を分担して連携する構想として整理しました。
なお、自動化の範囲、人による確認、問題発生時の停止や説明責任に関する記述は、公開資料を踏まえた筆者の考察です。実装状況や実際の運用範囲を保証するものではありません。
出典:AAA GitBook「1.6. Launchpad for AI-Agents」「2.4. Swarm Orchestration: AI Agents at Scale


🧭 この構想は、どのように受け取ればよいのでしょうか

ここまで見てきたように、Palo Alto Research Labの資料には、CRMからAIエージェントへ進んできた経緯と、その先にあるLaunchPadやOrchestration Layerの構想が示されています。

人と人をつなぐために情報を整理してきた仕組みが、AIエージェントを加え、さらに複数のAIが役割を分けて動く方向へ広がっている。
その流れ自体は、これからの仕事や組織のあり方を考える上で、興味深いものだと思います。

ただ、新しい仕組みほど、言葉の勢いだけで受け取らない方がよいとも感じます。

🔎 構想と、公開資料で確認できる情報を分けて見る

資料には、これから目指す方向や、実現したい仕組みが多く書かれています。
それは、運営側がどのような未来を描いているのかを知るための大切な情報です。

一方で、構想として示されていることと、すでに公開されている機能、実際にどこまで使われているのかは、同じではありません。

何を目指しているのか。
何が公開されているのか。
そして、何が実際に確認できるのか。


この三つを分けて見るだけでも、資料の読み方は少し落ち着いてくるのではないでしょうか。

🧑‍⚖️ 便利さを見る前に、確認の流れを見る

AIエージェントは、情報を集めたり、作業を整理したりする上で役に立つ可能性があります。
けれど、AIが提案した内容をそのまま採用してよいとは限りません。

どの情報を使ったのか。
誰が途中で確認するのか。
問題が起きた時、どこで止めるのか。

こうした流れが見えていることは、AIがどれだけ多くの仕事をこなせるかと同じくらい大切です。

私は、AIに任せる範囲を広げることよりも、人が確認し、必要なら止められる形を残すことの方が、長く使える仕組みにつながるように思います。

🙂 新しい言葉に、急いで結論を出さない

AIエージェント、Web3、Swarm Orchestration。
聞き慣れない言葉が増えると、期待だけが先に大きくなることがあります。

だからこそ、何が書かれているのかを読み、分からない部分は分からないまま残し、確認できることを一つずつ見ていく姿勢が大切です。

Palo Alto Research Labの構想も、完成した答えとして受け取るより、AIと人間の役割をこれからどう組み合わせていくのかを考えるための、一つの材料として見ることができるでしょう。

AIに何を任せるのか。人は何を確認し、何に責任を持つのか。

その問いを持ったまま資料を読むことが、AIエージェントの時代を落ち着いて見ていくための助けになるのではないでしょうか。

※本記事は、Palo Alto Research Labが公開しているAAA GitBookおよび関連する公式公開情報をもとに、筆者の見解を交えながら内容を整理したものです。
本文中の沿革、機能、構想に関する記述は、公開資料に記載された運営側の説明をもとにしています。より詳しい内容や最新の情報については、公式公開資料をご確認ください。


AIエージェント関連のおすすめ記事一覧はこちら

AIエージェント、CRM、Web3の仕組みや、AIと人の役割分担について考えるブログ内カテゴリーはこちら

AIエージェント関連記事一覧|リコ社長の構造都市ブログ
AIエージェントに関する最新の技術動向や経済的影響、自律型AIの活用事例などを解説。AIプロジェクトや Palo Alto Research Lab の動きも含めて整理しています。

※本記事は AI(ChatGPT等)を活用して作成・編集しています。
内容は運営者が確認・加筆を行っておりますが、誤情報が含まれる可能性があります。
必ず公式情報や一次情報と照合のうえ、ご判断ください。

🛡️ 免責事項(重要)

本記事は、Palo Alto Research Labが公開しているAAA GitBookおよび関連する公開情報をもとに、AIエージェント、CRM、AI Agents LaunchPad、Swarm Orchestrationに関する構想を整理・考察したものです。

本文中の沿革、機能、ロードマップ、将来像などに関する記述には、公開資料で運営側が示している内容をもとにした説明が含まれます。また、資料の読み取り方や、AIと人間の役割分担、確認の必要性などについては、筆者個人の見解・解釈が含まれています。

本記事は、特定のサービス、技術、組織、事業、投資商品、利用方法、導入判断を推奨・保証するものではありません。

AIエージェント、AI Agents LaunchPad、Swarm Orchestrationなどに関する説明は、公開資料上の構想や案内を整理したものです。本記事で触れた機能、連携、ロードマップ、運用範囲のすべてが、現在実装・提供・継続されていることを保証するものではありません。

技術やサービスの仕様、提供状況、利用条件、関連する制度や社会状況は、今後変更される可能性があります。本文は公開時点で確認できる情報をもとに作成していますが、将来的に内容が古くなったり、修正が必要になったりする場合があります。

本記事は、投資判断、利用判断、導入判断、契約判断、採用判断、法的判断などにおける最終的な意思決定を代替するものではありません。重要な判断を行う際は、最新の公式情報、一次資料、利用規約、必要に応じて専門家の助言など、複数の信頼できる情報源をご確認ください。

また、本記事の一部はAIによる文章生成を下地とし、運営者が内容を確認・編集したうえで公開しています。
本記事は、特定の結論へ誘導することではなく、公開資料を読むための視点と、読者ご自身が考えるための材料を提供することを目的としています。

新しい仕組みほど、急いで結論を出す必要はありません。距離を取り、立ち止まり、自分の言葉で確かめる時間を大切にしてください。
この記事が誰かの判断を縛るものではなく、考えるための静かな足場となることを願っています。

※内容は必要に応じて、予告なく更新・修正する場合があります。

📅 最終更新日:2026年6月20日

タイトルとURLをコピーしました