T最新テックトレンド

AIエージェントとワークフローの未来：複雑なシステムを構築するための実践的アプローチ

AI Engineer
0:00--:--

AI技術の進化が目覚ましい現代において、ソフトウェア開発の風景はかつてない変革期を迎えています。特に、大規模言語モデル（LLM）を基盤とした「AIエージェント」と、それらを連携させる「ワークフロー」の概念は、開発者がより複雑で自律的なシステムを構築するための鍵として注目されています。しかし、この急速な進化の中で、技術的なアプローチやベストプラクティスを巡る議論も活発化しています。

今回は、AI Engineer World's FairでのSam Bhagwat氏の講演から、このエキサイティングな分野の現状と未来について深く掘り下げていきます。Mastra.aiの創設者であり、Gatsbyの共同創設者でもあるBhagwat氏は、自身の豊富な経験と洞察に基づき、AIエージェントとワークフローを効果的に構築するための実践的な指針と、業界が直面する課題について語りました。

本記事では、彼が提示したホットテイクや具体的なデザインパターンを通じて、AIエージェントとワークフローの重要性、具体的な機能、ビジネスへの影響、そして将来性を専門的かつ分かりやすく解説します。

AIエージェントとワークフローをめぐる議論の深層

AIエージェントとワークフローは、LLMの能力を最大限に引き出し、現実世界の複雑なタスクを自動化するために不可欠な要素です。しかし、その定義や最適な構築方法については、いまだ活発な議論が交わされています。

Anthropicによるエージェントとワークフローの定義

2023年12月、Anthropicは「Building effective agents」という画期的なブログ記事を公開し、エージェントとワークフローの概念を体系的に整理しました。彼らのアプローチは、LLMを単なる予測エンジンとしてではなく、外部ツール、情報検索、記憶と連携することで「拡張LLM」として機能させるというものです。

拡張LLMの構成要素:

  • Retrieval（情報検索）: LLMが外部の知識ベースやドキュメントから関連情報を取得する機能。これにより、モデルは学習データに含まれない最新の情報や専門知識にアクセスできるようになります。
  • Tools（ツール）: LLMが外部システムやAPI（例：データベース、カレンダー、コード実行環境）と対話するための機能。これにより、モデルは単なるテキスト生成にとどまらず、具体的なアクションを実行できるようになります。
  • Memory（記憶）: LLMが過去の会話や経験を長期的に保持し、将来の意思決定に活かす機能。これにより、エージェントは文脈を維持し、より複雑なタスクを連続して実行できます。

Anthropicはまた、これらの拡張LLMを組み合わせるための様々なワークフローパターンを提示しました。

  • プロンプトチェーン (Prompt Chaining): LLMの連続した呼び出しをシーケンシャルに連結し、各ステップの出力を次のステップの入力として使用するパターンです。これは、複雑なタスクをより小さな、管理しやすいサブタスクに分解する基本的な方法です。例えば、ユーザーからの質問をまずLLMで解釈し、その結果をもとにデータベースを検索するツールを呼び出し、その検索結果を再度LLMで要約するといった一連の流れを構築できます。このプロセスでは、中間ステップでプログラマティックなチェック（「ゲート」）を設けることで、プロセスが適切に進行しているかを確認できます。
  • ルーティング (Routing): 入力を分析し、それに特化したLLMやツールに処理を振り分けるパターンです。例えば、カスタマーサポートのチャットボットにおいて、請求に関する問い合わせは請求処理LLMに、技術的な問題は技術サポートLLMにルーティングすることで、各LLMが専門性を最大限に発揮し、全体としてのパフォーマンスを最適化します。このワークフローは、関心の分離を可能にし、異なる入力タイプに対するパフォーマンスの偏りを防ぎます。
  • オーケストレーター・ワーカー (Orchestrator-Workers): 中央のLLM（オーケストレーター）がタスクを動的に分解し、ワーカーLLMに委譲し、その結果を統合するパターンです。これは特に複雑なタスクに適しており、例えばコード生成において、オーケストレーターが全体の計画を立て、個々の関数やファイルの変更をワーカーLLMに割り当て、最終的にそれらを統合するといった用途が考えられます。このパターンは、トポロジー的にはシンプルに見えるかもしれませんが、その柔軟性こそが重要であり、サブタスクが事前に定義されているわけではなく、オーケストレーターが入力に基づいて動的に決定します。

これらのパターンは、AIエージェントが単独のLLMでは達成できない複雑な目標を、より信頼性と効率性の高い方法で達成するための道筋を示しました。

OpenAIの論文と「アンチワークフロー」論争

しかし、2024年4月にOpenAIが発表した論文「A practical guide to building agents」は、Anthropicのブログ記事とは異なり、一部で強い反発を受けました。この論文は、エージェント構築の実践的なガイドを提供しようとしましたが、特に「宣言的フレームワークは非宣言的グラフである」という主張が物議を醸しました。OpenAIは、宣言的フレームワークが明示的なブランチ、ループ、条件フローをグラフ構築で要求するため、複雑で拡張性に欠けると示唆しました。

この「アンチワークフロー言語」とも呼ばれる主張に対し、Twitter（現X）では多くの開発者や識者から異論が唱えられました。Swyx氏のブログ記事「In the Matter of OpenAI vs LangGraph」などがその代表例です。批判の主なポイントは、OpenAIの論文が「既存の概念の多くを新しい言葉で再定義しているだけで、新たな知見に乏しい」「ワークフローの概念を不正確に捉えている」というものでした。

Bhagwat氏はこの議論について、モデル提供者のようなエコシステムにおける影響力のある立場にある企業が、誤解を招くような主張をすることで、この若い分野の議論を混乱させる可能性があると指摘しています。

「That Guy」にならないための教訓：健全な議論のために

Bhagwat氏のプレゼンテーションで最初に投げかけられた「Don't be That Guy」というホットテイクは、AI分野における健全な議論と技術開発のあり方に対する強いメッセージを含んでいます。

「That Guy」とは誰か？

「That Guy」とは、Bhagwat氏の定義によれば、「自分だけが開発の正しい方法を知っている」と信じ込んでいる人物を指します。彼らはしばしば、自身の信じるアプローチ以外を排斥し、異なる視点や技術を不不適切だと主張します。

特に問題となるのは、この「That Guy」がFANG（Facebook, Amazon, Apple, Netflix, Google）のような巨大テクノロジー企業や、OpenAIのようなAI分野のリーディングカンパニーの公的な役割を担っている場合です。彼らの発言は大きな影響力を持つため、誤った情報や偏った視点が業界全体に広がり、革新を阻害する可能性があります。

Web開発の歴史からの教訓

Bhagwat氏は、Web開発の歴史を例に挙げてこの点を強調しました。過去数十年間、Web開発者はGoogleの特定のエンジニアたちから「プラットフォームを使え」という講義を度々受けてきました。この「プラットフォームを使え」という言葉は、しばしばReactのような人気の高いフレームワークを批判し、代わりにGoogleが推進するPolymerやWeb Componentsといった、当時は使いこなしが非常に困難であった特定の技術を採用するよう促すための暗号のようなものでした。この結果、多くの開発者が混乱し、技術選択に不必要な制約を感じることになりました。

AI分野における「That Guy」の出現を避ける

Bhagwat氏は、AIエンジニアリングの分野で同様の状況が繰り返されることへの懸念を表明しました。LLM提供企業は、その技術的な優位性からエコシステム内で極めて高い地位を占めており、彼らの発言は大きな重みを持っています。そのため、彼らが「これが唯一の正しいやり方だ」と主張することは、多様なアプローチやオープンなイノベーションの芽を摘んでしまう恐れがあります。

AI分野はまだ発展途上であり、多くの未知の可能性を秘めています。Bhagwat氏は、モデル提供者を含むすべての関係者が、よりオープンで包括的な議論を促進し、異なる技術的アプローチを尊重することの重要性を訴えました。私たちが望むのは、互いに学び合い、協力し合うことで、真に質の高い技術的進歩を達成することです。

グラフ理論が不要なワークフロー設計：直感的なAPIの追求

Bhagwat氏の2つ目のホットテイクは、「『Graph』『node』『edge』のようなグラフ理論的な用語を用いたフレームワークAPIは有害である」というものでした。これは、LangChainのような人気のあるAIフレームワークが採用しているアプローチに対する直接的な批判であり、より直感的でアクセスしやすいワークフロー設計の必要性を訴えるものです。

Gatsbyの共同創設者としての経験

Bhagwat氏は、自身がReactのメタフレームワークであるGatsbyの共同創設者であった経験を振り返ります。2017年頃、Gatsbyはデータフェッチのデフォルト方法としてGraphQLを採用しました。GraphQLはデータの取得方法に柔軟性をもたらし、多くの点で画期的な技術でしたが、「ノード（node）」や「エッジ（edge）」といったグラフ理論に由来する概念をAPIに組み込んだことで、一部のユーザーには学習コストが高く、直感的に理解しにくいという課題が生じました。

GraphQL自体は素晴らしい技術であり、今も多くの場所で活用されています。しかし、Gatsbyの経験から学んだのは、一部のユーザーはそのグラフ理論的なアプローチを好んだ一方で、多くのユーザーはよりシンプルなReactメタフレームワークを求めており、Next.js, Astro, Viteといった他のフレームワークを選んだという事実でした。彼らは、複雑なデータ構造を扱うためにグラフ理論を学ぶことを望んでいなかったのです。

直感的なワークフローAPIの重要性

この経験からBhagwat氏は、「ワークフローを構築するためにグラフ理論を学ぶ必要はない」という結論に至りました。プロダクションレベルのアプリケーションを開発する開発者にとって、学術的な概念を深く理解することなく、コードの意図を明確に把握し、効率的に作業できることが重要だからです。

彼は、Mastraのようなフレームワークが提供する、より「理解しやすい（grokabble）」ステートフルなワークフローパターンを例示しました。

// Mastra
myWorkflow
  .parallel([step1, step2]) // step1とstep2を並行実行
  // 両方の並行ステップが完了した後に続行
  .then(step3) // その後step3を実行
  .commit();

この例では、.parallel()や.then()といったメソッドチェーンを用いることで、ワークフローの順序や並行処理が非常に明確に表現されています。開発者はコードを上から下へと読むだけで、各ステップがどのように連携し、いつ次のステップが実行されるのかを直感的に理解できます。

また、より一般的な非同期処理のパターンであるPromise.allとasync/awaitを用いたワークフローの記述も例として挙げられました。

// Ingest
const [notifyTeam, assignPlan] = await Promise.all([
  step.run("notify_team", async () => {
    // チームに通知するロジック
    return { notified: true };
  }),
  step.run("assign_default_plan", async () => {
    // デフォルトプランを割り当てるロジック
    return { planId: "starter" };
  }),
]);

このようなコードは、JavaScript開発者にとっては馴染み深く、複数の非同期処理が並行して実行され、その結果がどのように集約されるかが一目で分かります。

Bhagwat氏は、チームでソフトウェアを開発する際には、コードの可読性が極めて重要であると強調します。誰もが複雑なグラフ理論を学ぶことなく、ワークフローのロジックを理解し、修正できるべきだからです。難解なAPIは、チームの生産性を低下させ、エラーの原因となる可能性があります。したがって、AIエージェントとワークフローのフレームワークは、技術的な深い理解を前提とせずとも、直感的に使えるデザインを追求すべきだというのが彼の主張です。

AIエージェントとワークフローのデザインパターン：組み合わせの妙技

これまでの議論を踏まえ、Bhagwat氏はAIエージェントとワークフローの「デザインパターン」について語りました。ここでいうデザインパターンは、ソフトウェア工学の分野で広く知られる「Gang of Four」のデザインパターンに先行する、建築家クリストファー・アレクサンダーの著書「A Pattern Language」に由来する概念です。アレクサンダーは、都市計画から建築設計に至るまで、人間にとって快適で機能的な空間を創造するための普遍的な「パターン」をカタログ化しました。Bhagwat氏は、AIエージェントとワークフローの構築においても、同様の普遍的なパターンを見出し、共有する「パターン・ランゲージ」が必要であると提唱しています。

エージェントとワークフローの普遍的な定義

この「パターン・ランゲージ」を確立するためには、まずエージェントとワークフローの共通の理解が必要です。WorkOSが提唱する定義は以下の通りです。

エージェント:

  • 会話の記憶を保持する。
  • ワークフローを自律的に実行する。
  • 文脈に基づいて意思決定を行う。
  • ツールを使用してタスクを完了する。 これらは、記憶と能力を備えたAIアシスタントと考えることができます。エージェントは、人間からの指示を受け、自律的に思考し、行動することで、複雑な目標達成を目指します。

ワークフロー:

  • 複数のステップを連結する。
  • ステップ間でデータを渡す。
  • Zodのようなライブラリで入力/出力を検証する。
  • エラーを適切に処理する。 これらは、型付けされ、観測可能な関数として、複雑な多段階操作を実行する構成可能なパイプラインと考えることができます。ワークフローは、複数のタスクやエージェントの連携を構造化し、一貫した処理を実現するための基盤となります。

エージェントとワークフローの別の捉え方

Bhagwat氏は、これらをより分かりやすいアナロジーで表現しました。

  1. エージェントはターン制のゲームである: ユーザーとエージェントが交互にターンを取り、対話を通じて目標達成を目指すイメージです。エージェントはユーザーからの入力に基づいて行動し、その結果をユーザーに返し、また次の指示を待ちます。この往復運動は、エージェントが記憶を保持し、文脈に応じた適切な行動を選択することの重要性を示しています。
  2. ワークフローはテックツリーのルールエンジンである: Civilizationのようなストラテジーゲームに登場する「テックツリー」のように、特定の技術（ステップ）を開発（完了）する前に、他の技術（前提となるステップ）が必要となる依存関係の集合体と考えることができます。例えば、「青銅器」を研究しないと「鉄器」を研究できないように、ステップBを完了するにはステップAが必須といった順序付けが存在します。ワークフローは、このような複雑な依存関係を持つ一連のデータパイプラインとして機能し、ステップA、ステップB、ステップCと順に実行されることで、全体として大きなタスクを完了します。

ワークフローの重要性が増している理由

ワークフローの概念自体は新しいものではありませんが、AIエンジニアリングの分野でその重要性が格段に高まっているのには明確な理由があります。

LLMの非決定論性: 大規模言語モデルは本質的に非決定論的です。同じ入力に対しても、異なる出力や推論プロセスを生成することがあり、予測が困難な場合があります。この特性は、従来のソフトウェア開発における決定論的なシステムとは大きく異なります。

この非決定論性のため、AIエージェントやエージェンティックなアプリケーションでは、以下の要素が従来のソフトウェア工学よりもはるかに重要になります。

  • Instrumentation（計装）: システムの内部状態や動作を監視し、データを収集する機能です。これにより、エージェントがどのような思考プロセスを経て、どのツールをいつ呼び出したかなどを詳細に追跡できます。
  • Tracing（トレース）: システムの実行パスを記録し、問題発生時の原因究明を容易にする機能です。非決定論的なLLMの振る舞いを理解し、デバッグするためには、詳細なトレースが不可欠です。
  • Replayability（再現性）: 特定の入力に対して、過去の実行を正確に再現できる機能です。これにより、バグの修正やパフォーマンスの最適化を行う際に、一貫したテスト環境を確保できます。

これらの要件を満たすためには、柔軟で堅牢なワークフローの仕組みが不可欠です。ワークフローは、LLMの非決定論的な部分を隔離しつつ、全体としてのシステムの信頼性、観測可能性、管理可能性を高める役割を担います。

パワーとコントロールのトレードオフ

Bhagwat氏は、エージェントとワークフローの設計は常に「パワー」と「コントロール」のトレードオフであると説明します。

  • マルチエージェントシステム: 複数のエージェントが自律的に相互作用するシステムは、高い「パワー」を持ち、予測不可能な方法で複雑な問題に対処する可能性があります。しかし、その自律性ゆえに「コントロール」が難しく、挙動の予測やデバッグが困難になることがあります。
  • エージェント: 単一のエージェントは、マルチエージェントほどではないが、依然としてある程度の自律性とパワーを持ちます。
  • ワークフロー: 厳密に定義されたワークフローは、高い「コントロール」を提供します。各ステップの実行順序、入力、出力が明確であるため、システムの挙動を予測しやすく、デバッグや最適化も容易です。しかし、その分「パワー」や自律性は制限される可能性があります。

このトレードオフにおいて、最適なバランスを見つけることが重要です。初期段階ではより多くのパワーを許容し、問題が発生した際にコントロールを追加していくアプローチや、特定の部分で高いコントロールを維持しつつ、他の部分でエージェントにパワーを与えるアプローチなど、ユースケースに応じて適切な組み合わせを選択する必要があります。最終的に、多くのタスクでは、これらの要素を適切に組み合わせることが不可欠です。

実践からの学び：エージェントとワークフローの構成ルールと具体例

Bhagwat氏は、これまでの議論を踏まえ、数百回に及ぶホワイトボードセッションから得られた実践的な教訓として、エージェントとワークフローの組み合わせ方に関する「構成ルール」を提示しました。そして、これらのルールを組み合わせることで生まれる「魔法」を具体的な例で示しました。

エージェントとワークフローの構成ルール

これらのルールは、AIエージェントとワークフローの設計における基本的なビルディングブロックと、それらをどのように組み合わせるかについての指針を提供します。

  1. エージェントはツールを持つ: エージェントは、外部システムと対話したり、特定のタスクを実行したりするために、様々なツールを呼び出すことができます。
  2. ワークフローはステップを持つ: ワークフローは、一連の順序付けられた、または並行するステップで構成されます。
  3. エージェントはステップになりうる: ワークフロー内の1つのステップとして、エージェントを組み込むことができます。これにより、ワークフロー内でエージェントの自律的な意思決定能力を活用できます。
  4. ワークフローはツールになりうる: エージェントが呼び出すツールとして、より複雑なロジックをカプセル化したワークフローを使用できます。これにより、エージェントの能力を拡張しつつ、ツールの内部ロジックを構造化できます。
  5. エージェントはツールになりうる: エージェントは、別のエージェントのツールとして機能できます。これにより、エージェント間の階層的な連携や協調作業が可能です。
  6. ワークフローはステップになりうる: これはルール2と重複するように見えますが、Bhagwat氏が強調しているのは、複雑なサブプロセスを別のワークフローとして定義し、それをメインワークフローのステップとして利用することで、ネストされた構造を構築できるということです。

Bhagwat氏は「ほとんどのプリミティブと同様に、それらを組み合わせたときに魔法が起こる」と述べ、これらの基本的な要素を柔軟に組み合わせることで、強力で適応性の高いAIシステムを構築できると強調しました。

具体的な組み合わせパターンの例

これらの構成ルールがどのように実践で活かされるか、Bhagwat氏はいくつかの具体的な例を提示しました。これらの例は、MastraのTypeScriptコード形式で示されており、その簡潔性と可読性を際立たせています。

  1. エージェント・スーパーバイザーモデル:

    • このパターンでは、一つの「スーパーバイザーエージェント」が、特定のタスクを実行する複数の他のエージェントを「ツール」として利用します。
    • 例として、researchAgent（研究タスクを分析する）とsummaryAgent（詳細な情報を要約する）という2つのエージェントが存在します。
    • supervisorAgentは、これらの2つのエージェントをツールとして設定し、ユーザーからの問い合わせに応じて適切なエージェントを呼び出します。例えば、ユーザーが特定のトピックに関する情報収集と要約を求めた場合、supervisorAgentはまずresearchAgentを呼び出して情報を集めさせ、その結果をsummaryAgentに渡して要約させることができます。
    • このモデルにより、複雑なタスクを専門的なエージェントに委譲し、全体的なプロセスを効率化できます。コードは、各エージェントの定義と、supervisorAgentがresearchToolとsummaryToolをどのように利用するかを明確に示しています。

  2. ツールとしてのワークフロー:

    • ここでは、ワークフロー自体がエージェントのツールとして機能する例が示されます。
    • 例のエージェントは、ユーザーの場所を尋ね、天気をチェックし、旅行を計画するという指示を持っています。
    • checkWeatherとplanTripという2つのワークフローが定義されており、これらがエージェントのworkflowsプロパティに組み込まれます。
    • エージェントは、会話の流れに応じてこれらのワークフローをツールのように呼び出し、複雑なステップを含むタスクを効率的に実行できます。これにより、エージェントは高度な機能を持ちつつ、その内部実装（ワークフローの各ステップ）は独立して管理されます。

  3. エージェントのハンドオフを行うワークフロー:

    • このパターンでは、ワークフローが異なるエージェント間のタスクの受け渡し（ハンドオフ）を管理します。
    • researchAgentとsummaryAgentというエージェントが存在します。
    • agentHandoffWorkflowというワークフローが作成され、これが最初にresearchAgentのステップを実行し、その結果を受けてsummaryAgentのステップを実行するという形で、両エージェント間の連携を定義します。
    • この構造は、一方のエージェントが完了したタスクの出力を他方のエージェントの入力としてシームレスに渡すことを可能にし、複雑な共同作業をスムーズに進めます。

  4. 動的なツール注入:

    • この高度なパターンは、エージェントに与えるツールを、実行時のコンテキスト（例：ユーザーのティア）に基づいて動的に変更する方法を示します。
    • Dynamic Support Agentというエージェントが、runtimeContextからユーザーのティア（「pro」または「enterprise」）を取得します。
    • ユーザーのティアが「pro」であればadvancedAnalyticsツールを追加し、「enterprise」であればcustomIntegrationツールを追加するという条件分岐ロジックがtools関数内に記述されています。
    • これにより、エージェントはユーザーのニーズや権限レベルに応じて最適なツールセットを動的に構築し、よりパーソナライズされた、またはセキュアなサービスを提供できます。これは、エージェントの適応性とセキュリティを高める上で非常に強力な機能です。

  5. ネストされたワークフロー:

    • ワークフローが他のワークフローをステップとして含む「ネストされたワークフロー」の概念も紹介されました。
    • nestedWorkflowという独立したワークフローがあり、これがmainWorkflowのステップの一つとして呼び出されます。
    • mainWorkflowはinitialStep、nestedWorkflow、finalStepという順序でステップを実行します。
    • この階層的な構造により、大規模で複雑なプロセスをモジュール化し、管理しやすくすることができます。各サブワークフローは独立して開発・テストが可能であり、全体のシステム設計の複雑性を低減します。

これらの例が示すように、エージェントとワークフローのプリミティブはシンプルであるにもかかわらず、それらを組み合わせることで驚くほど多様で強力なシステムを構築できます。Bhagwat氏は、「現実は驚くほどの詳細さを持っている」とし、プロダクション環境で動作するエージェンティックなワークフローも同様に詳細な考慮が必要であると結びました。真の「アルファ」は、これらのパターンを適切に組み合わせ、現実世界の複雑な課題に対応する能力にあるのです。

結論：AIエンジニアリングにおける実践と理論の調和

Sam Bhagwat氏の講演は、AIエージェントとワークフローの構築が単なる技術的な課題にとどまらず、哲学的な問いやコミュニティのあり方にまで及ぶことを示唆しました。

AIエンジニアリングはまだ黎明期にあり、その進化は急速です。Bhagwat氏が指摘するように、この分野では「理論よりも実践が先行している」のが現状です。多くの開発者が試行錯誤を重ね、現実世界での具体的なユースケースを通じて、何が機能し、何が機能しないのかを学んでいます。このダイナミックな環境では、既存の概念を新しいラベルで再パッケージ化したり、特定のツールやアプローチを唯一の「正しい道」として押し付けたりする「That Guy」の存在は、イノベーションを阻害しかねません。

Bhagwat氏が提示した「グラフ理論を学ぶ必要のないワークフロー」や、エージェントとワークフローの柔軟な「構成ルール」は、まさに実践的な視点から生まれた洞察です。コードの可読性を高め、開発者が直感的に理解・利用できるAPIを設計することの重要性は、チームで信頼性の高いAIシステムを構築する上で不可欠です。LLMの非決定論性という特性は、計装、トレース、再現性をこれまで以上に重視するワークフローの設計を求めます。そして、マルチエージェントの「パワー」とワークフローの「コントロール」の間の適切なトレードオフを見つけることが、成功への鍵となります。

最終的に、AIエンジニアリングの分野は、オープンな議論、実践からの学び、そして多様なアプローチへの尊重を通じて、その「パターン・ランゲージ」を確立していくことになるでしょう。私たちは、互いの経験を共有し、協力し合うことで、より堅牢で、より創造的で、より社会に貢献できるAIシステムを構築できるはずです。

Sam Bhagwat氏の「Principles of Building AI Agents」という著書がこのカンファレンスで配布されたように、私たちは皆、この新しいフロンティアを切り開く共同のジャーニーに参加しています。彼のメッセージは、私たち全員が、AIの未来を形作るための責任ある、そして協力的なアプローチを取ることを促すものです。

私たち一人ひとりができること

  • オープンな対話を促進する: 自分のアイデアを共有し、他者の意見に耳を傾けることで、質の高い議論を育みます。
  • 実践から学ぶ: 理論だけでなく、実際にコードを書き、システムを構築し、そこから得られる教訓を重視します。
  • デザインパターンを共有する: 成功したアプローチや解決策をパターンとして言語化し、コミュニティと共有することで、知識の普及と再利用を促進します。
  • トレードオフを意識する: すべての解決策には利点と欠点があることを理解し、特定のコンテキストにおいて最適なバランスを見つけることに努めます。

AIの時代は始まったばかりです。この新しい世界を共に築き上げていきましょう。

参考情報:

  • Mastra.ai: https://github.com/mastro-ai/mastro
  • Sam Bhagwat氏のX/Twitter: @calcsam
  • Christopher Alexander著「A Pattern Language: Towns, Buildings, Construction」
  • Anthropicブログ記事「Building effective agents」 (2023年12月19日公開)
  • OpenAI論文「A practical guide to building agents」 (2024年4月公開)
  • Swyxブログ記事「In the Matter of OpenAI vs LangGraph」

（この記事は、AI Engineer World's FairでのSam Bhagwat氏のプレゼンテーションから得られた情報を基に、ジャーナリストの視点で再構成したものです。）

← 一覧に戻る