この動画では、n8nを使用したAIエージェント構築における最大の落とし穴と、それを回避する実践的な方法論について解説している。多くの企業や個人がn8nの視覚的ワークフロービルダーに魅力を感じて導入するものの、複雑性の罠に陥り、保守不可能なシステムを構築してしまう問題を詳細に分析。成功事例として、18個のノードのみで複雑なポルトガル官僚制度ナビゲーション事業を運営するBorderや、200時間/月の工数削減を実現したDelivery Heroの事例を紹介しながら、シンプルさの原則、関心の分離、適切なドキュメント化の重要性を強調している。特にJSON表現を活用したLLMとの協働アプローチや、チームレベルでの運用体制構築の必要性について具体的な指針を提供している。
- n8nでAIエージェント構築を始める前に知っておくべきこと
- 包括的ガイドとゴルディロックス・ユースケース
- 複雑性の罠と現実の課題
- 成功の鍵：シンプルさと明確さ
- JSON表現の活用とLLMとの協働
- ソフトウェア構築としてのエージェント開発
- ドキュメンテーションと保守性の重要性
- 成功事例：複雑な問題のシンプルな分解
- 関心の分離とマイクロサービスの概念
- 実践的な成功例：Delivery Heroのケース
- AIエージェントは新しいソフトウェア開発の形
- 個人の自動化からチームプロダクトへの転換
- チーム問題としてのエージェント自動化
- LLMがn8nにもたらす多方向の加速効果
- 真のROIを実現するための原則
- まとめ：規律ある長期的アプローチの重要性
n8nでAIエージェント構築を始める前に知っておくべきこと
今日は、AI分野で最も頻繁に寄せられる質問の一つに対する重要な答えをお伝えしたいと思います。それはAIエージェントについて、特にAIエージェントの構築を始めたいけれど、自分にはまだ十分な技術力がない、コードだけで実装するほどのスキルもないという状況についてです。だからLangchainやLang Smithは使わない。シンプルなエージェント、実際に使えるエージェント、そしてカスタムエージェントが欲しいのです。
Lindy.aiのような、多くの既製エージェントと一定の組み合わせ機能を持つツールは、私が話すこの状況の人々には制限的に感じられます。一方、n8nのようなツールは、より組み合わせ可能で、よりカスタマイズ性が高く、多少のコードも持ち込めるので、まさに適切に感じられます。遊び場にいるような感覚になるのです。
しかし、エージェントを始めようとしているなら、その組み合わせ可能性、設定可能性、n8nで感じるパワーこそが罠だということを認識する必要があります。それが罠なのです。だからこそこの動画が存在するのです。
n8nのようなものから始めた人々は、とても興奮し、目に星が浮かび、AGIを感じ、AIエージェントを感じます。あらゆるクールなことができると分かり、そしてAIエージェントが壊れることを発見するのです。ビジネス全体に556個のエージェントがあり、そのうち332個に何が起こったのか神のみぞ知る状況で、定期的に使われているのはわずか50個だけ、しかも全て大きな請求書につながっていることを発見します。エージェントを構築した人が休暇に行き、今度は修正方法が分からない。このドラッグアンドドロップが作り出した絡み合った混乱で、何も見えないからです。
これらは全て実例です。何度も何度も見てきました。この動画は、カスタムエージェントをやりたいから、カスタムエージェントができるまでのお手伝いをします。n8nを使える、素晴らしいツールだが、うまく使う方法を知っている。エージェント構築時のベストプラクティスに従う方法を知っていて、それを実現するためにカスタムコーダーである必要はないという状態に導きます。
包括的ガイドとゴルディロックス・ユースケース
私はエージェントについて包括的なガイドを書いてきました。これはより狭く焦点を絞っていますが、非常に包括的で、私がゴルディロックス・ユースケースと呼ぶものに特化しています。カレンダー用の既製エージェントが欲しいだけという極端に箱から出してすぐ使いたい場合でもなく、開発者で何でもできるという極端に自由なスタイルでもない。その中間です。
コードライフスタイルにコミットすることなく、カスタマイズ性を求める人々のためのものです。この分野にいるなら理解すべき第一の真実は、n8nには自動化を真に民主化する視覚的ワークフロービルダーがあり、それが人々がそこに引き寄せられる理由の一部だということです。初めて、プログラマーでない人でも、小さなノードを小さなツリーにドラッグアンドドロップするだけで、洗練されたAIエージェントを構築することが本当に可能になったのです。そしてこれは実際に機能します。
第二の真実は、すでにほのめかしましたが、同じ視覚的ビルダーが複雑性の罠だということです。非常に多くのn8n実装を殺してきました。皮肉にも、使いたくなる機能そのものが、スケールで保守不可能になる機能なのです。
しかし、心配無用です。その道筋をお示しします。n8nをインストールして最初のノードの構築を始め、画面上でデータが流れるのを見始めるハネムーン期から、スーパーパワーを解放したように感じ、さらに10個作りたくなる状態から、幻滅の谷を通り抜けて加速させたいと思います。
複雑性の罠と現実の課題
エラーハンドリングを追加し、条件付きロジックを追加しなければならない段階に入ると、さらに多くのノードが必要になります。エッジケースが積み重なります。管理可能だと自分に言い聞かせますが、クリーンなワークフローはマンハッタンの地下鉄路線図のように、ばかげた見た目の、スパゲッティの山のようになります。
ある時点で、真剣に取り組んでいて、ノードをドラッグアンドドロップするだけなら、12個のワークフローと633個のノードを持つ状況に到達し、午前2時に失敗し、3時間かけてデバッグに費やし、地獄にいるような気分になるでしょう。これは信じられない苦痛です。
入力を正しくシミュレートできません。失敗したノードがあります。LLMが更新されたために異なるLLM呼び出しがあります。失敗時にエラーオブジェクトがあり、それが何を意味するのか分かりません。ここで実際にアプローチを変えることができます。
その道を辿る必要はありません。実際に役に立つエージェントを構築することができます。実例として、実在の企業StepStoneは、n8nで200個のミッションクリティカルなワークフローを運用しています。APIインテグレーション時間で約25倍のスピードアップを達成しました。
成功の鍵：シンプルさと明確さ
200個のワークフローには集中が必要です。企業規模で実行するなら、n8nをエクセレンスハブのように扱う必要があります。製品、マーケティング、CSチームが技術チームと出会い、皆が信頼性があり、シンプルで、明確で、追跡可能なワークフローの作成に集中できる場所として。
そして、これは何度も何度も強調することですが、構築するときは、信頼性があり、シンプルで、明確であることを確実にしてください。あなたは言うかもしれません、ネイト、この動画全体がn8nのワークフローが複雑だと言っているだけなのか？そんなことはもう知っている、と。いいえ、これはワークフローをJSON表現に入れることで、より遠くまで行けることを提案しているのです。
JSON表現は、ワークフローをできるだけシンプルにすることに執着するLLMで通常構築するため、シンプルさを強制する傾向があるからです。ワークフローのJSON表現はキッチンの指示のようなものです。シェフに何を作るかを伝えるのです。それらが強力である理由の一つは、ワークフローをドラッグアンドドロップできるだけでなく、このプログラマティックなキッチン指示のようなこともできることです。シェフにJSONワークフローを手渡して「これをやって」と言えば、機能するのです。
JSON表現の活用とLLMとの協働
JSON表現がここで有用であることを提案したいと思います。LLMがJSONで何らかの魔法の力を持っているからではありません。ウェブでそれが回っているのを見て、ちょっと目を丸くしました。ここで言おうとしているのはそういうことではありません。単純に、JSONは、n8nというこの特定のツールが理解し、LLMがうまく書け、あなたが持つ明確なビジョンのキャリアや器として使える、良い取り込み方法だということです。
JSONはあなたにとっての簡略化装置として機能します。Claude、ChatGPTと協働してn8n自動化用のJSONワークフローを構築するなら、特にn8nがワークフローやツール呼び出しについて公開しているドキュメンテーションを呼び出すなら、機能するワークフローを得られる可能性が格段に高くなります。そうすればLLMはワークフローを書く際にそれを知り、エラーが発生する可能性が低くなります。
また、エージェント構築の事業をしているなら、開発者でなくても、ソフトウェア構築の事業をしていることを理解する方が良いということも提案したいと思います。それで怖がらせるつもりはありませんが、人々が驚かないよう、正直に伝えようとしています。
ソフトウェア構築としてのエージェント開発
効果的に、プログラミングの代わりに設定をしているので、より簡単に感じますが、実際にはより戦略的になります。あなたの側でより多くの思考と意図が必要になります。そして、ほとんどのソフトウェアエンジニアがDNAに組み込んでいるが、他の職種には組み込まれていないことを理解する必要があります。
私はあなたのエージェントがより良く機能するよう、そのギャップを埋めるためにここにいます。シンプルさの原則から始めましょう。維持するために、可能な限り無慈悲にシンプルなワークフローを構築する必要があります。シンプル、シンプル、シンプル。頭に叩き込んでください。
理由は、シンプルは保守可能だからです。これが、エンジニアがコードベースのバックエンドをリファクタリングする必要があると言う理由です。そして、あなたは彼らが何をしているのか疑問に思います。教えてあげましょう、エンジニアたちはうなずいています。彼らは何をしているか知っています。コードベースのバックエンドをリファクタリングしなければならないのは、それをシンプルで保守可能でスケーラブルにしなければならないからです。
シンプルはスケーラブルです。シンプルは保守可能です。シンプルは読みやすいです。効果的に、n8nとエージェントで持っているのは、機能とドキュメンテーションの組み合わせを一つの形式で持っているということです。マンハッタンの地下鉄路線図のように見えるそのスパゲッティコードは、ワークフローの実際の図でもあり、唯一のドキュメンテーションでもあります。だからこそ、そんなに痛いのです。
ドキュメンテーションと保守性の重要性
これらのワークフローをJSONで構成することの利点は、より正確になれるだけでなく、シンプルになる可能性が高いことです。シンプルさに偏見を持つLLMと作業している場合、シンプルであるように伝えることができます。そうすれば、そこに到達する手助けをしてくれます。また、まったく同じLLMを使用して、あなたが提供するJSONのドキュメンテーションを書くこともできます。
これがドキュメンテーションなので、保存でき、維持でき、なぜその決定を下したかを知ることができます。あなたがソロビルダーでない限り、あなただけが維持するのではない状況になりたいので、そうすることをお勧めします。ちなみに、この方法で機能するソロビジネスを持つことは可能です。
これを実行した小規模ビジネスの例として、Border（BORDR、Eを削除）という会社があります。彼らはポルトガルの官僚制度をナビゲートする手助けをする実際のビジネスを構築しました。これは国外駐在労働者の動き、世界中で働けるノマド運動などの一部です。彼らはn8nを使用してそれを実行しました。運営全体がn8nワークフローで動いています。
彼らのコアワークフロー用のn8n上のあの小さなボックスがいくつあるか推測してほしいです。さあ、推測してください。推測しましたね。素晴らしい。18個です。180個ではなく、18,000個でもありません。18個です。
彼らは複雑性がリスクを複合化することを理解しています。複雑性は自動化でも指数関数的に複合化します。これは基本的なグラフ理論です。開発者なら、追加するノードごとに、維持すべきことが一つ増えるだけではないことを知っています。非常に多くの他のノードとの相互作用を追加するのです。10ノードのワークフローには約45の可能な相互作用点があります。20ノードのワークフロー、たった10個多いだけで、190になります。50ノードのワークフローなら1,200を超えます。
成功事例：複雑な問題のシンプルな分解
ポルトガルの官僚制度は伝説的に複雑で、だからこそこのビジネスが存在します。彼らのワークフローがシンプルなのは、問題がシンプルだからではなく、複雑な問題を組み合わせ可能な部品に分解する方法を理解していたからです。
すべてのワークフローは一つのことを行います。それをうまく行い、素早く理解できます。これはソフトウェアエンジニアリングの原則で、n8nを始めてエージェントを構築する人々、そのゴルディロックス・バケットにいる人々には十分に理解されていないと思います。そのほぼ全員が非技術側から来る傾向があります。
ちなみに、これを聞いているエンジニアなら、この動画は、マーケティング部長がホワイトボードに馬鹿げて複雑なノードを描いて「これがエージェントに欲しいものです」と言ったときの、あなたの免罪符のようなものです。そしてあなたは内心叫んでいます。これを見せてください。シンプルさの原則は重要です。本当に重要なのです。
関心の分離とマイクロサービスの概念
ちなみに、意図的に組み合わせ可能な部品と言いました。ソフトウェアエンジニアリングの基本的側面の一つが、関心の分離という考え方です。別の言い方をすれば、物事は適切な場所に行くということです。後でうまく管理できるよう、関心をきちんと整理しておくのです。より大きなスケールでは、ここからマイクロサービスの考え方が生まれます。
少し脱線しますが、私はAmazonで働いていて、AmazonはマイクロサービスとAPIの考え方が生まれた場所です。はい、他の多くのものと一緒に私たちが発明しました。それを呪いと考えるか祝福と考えるかは分かりませんが、とにかくあなたも持っています。
マイクロサービスは、関心の分離がソフトウェアにおいて非常に重要で、それがないとある時点でスケールできないという考えです。私たちはモノリスを構築することからコーディングを始めました。n8nでいうマンハッタンの地下鉄路線図と呼ぶようなもの、それがソフトウェアでした。15、20年前のAmazonでも、すべてが一つの巨大なコードベースでした。
コードベースがどんどん大きくなると、それを維持するのが本当に困難になります。コードの一部が何に触れるか分からないのです。休暇を取らないシニアエンジニアだけが知っています。彼がバスに轢かれないことを神に祈ります。
マイクロサービスが存在したのは、実際に構築するために存在する必要があったからです。関心を分離する必要がありました。そして今では、あまりにも明らかに良いアイデアなので、すべてのエンジニアがそれについて知っています。ソフトウェアのコンポーネントを分離します。それらのコンポーネントがデータとビジネスルールを交換する方法を標準化します。それをAPIと呼びます。そして、きれいに管理できる別々の関心事を持つのです。
エージェントを構築するときは、この原則を適用してください。すべてを行うモノリスエージェントを構築してはいけません。関心事をきれいに分離してください。特定のエージェントで一つか二つのことだけを行うように、きれいに分離してください。焦点を当てることは本当に、本当に重要です。
実践的な成功例：Delivery Heroのケース
別の例を挙げましょう。これも実例です。Delivery Heroは、n8n自動化で月に数百時間を節約しています。数百のリクエストを自動的に処理しています。そして、彼らが何を自動化したか気づいてください。ITアカウント復旧です。IT部門全体ではなく、従業員リクエストでもなく、一つの明確に定義されたプロセスです。
これは私の言っていることを強化しています。エージェント実装で成功したいなら、根本的に焦点を当てなければなりません。一つのプロセスを特定してください。それは痛みを伴う必要があり、頻繁である必要があり、本当によく定義されて良い境界がある必要があります。それを最後まで自動化してください。実行してください。それに執着してください。何が壊れるかを学んでください。壊れた部分を修正してください。成熟し、持続可能で、よく文書化されたときにのみ、次のプロセスに移ってください。
私が見る典型的な失敗パターンはその逆です。チームは痛みを明確に定義しません。境界がどこにあるか分かりません。セミナーでAIエージェントを使えと言われて興奮し、一度にすべてを自動化しようとします。巨大で広がるワークフローを構築し、複数のシステムに触れ、信じられないほど見栄えがよく、初日にはすべて動き、CEO発表があり、理解していない依存関係を作成しています。
そして何かが壊れるとき、必ず壊れます、壊れることを計画してください、問題を分離できません。CEOがAIエージェントで勝利宣言をしたため、皆が次のプロジェクトに移っているため、もはや誰も地図を読めないからです。AIエージェントはチェックボックスではありません。
AIエージェントは新しいソフトウェア開発の形
AIエージェントを実装したいなら、このように実装してください。多くのチームがそうしています。AIエージェントは、皆のためのソフトウェアを行う新しい方法です。そして、皆のためのソフトウェアを行うことは可能です。
Claude、ChatGPT、Gemini、さらにはGrokなど、お気に入りのLLMと作業すれば、自分でこれを構築し、私が提案していることに沿って構築できる地点に到達できると固く信じています。シンプルで、組み合わせ可能で、実際の痛み点を修正するなど。それを行うためにエンジニアを持つ必要はありませんが、実際のエンジニアリング作業をしていることを認識しましょう。実際にソフトウェアを構築しているのです。
これがAI時代の魔法の一部です。この種の明確な意図でこの方法で考える意思があるなら、あなたもソフトウェア構築の仕事ができ、真の自動化から得られる魔法、真のROIを生成できます。
Delivery Heroが月に200時間節約していると言ったことを覚えていますか？実際にそうしています。実際です。なぜなら、スケールでは多くの人がITアカウントの復旧を必要とし、それは非常に予測可能なワークフローであり、復旧できるからです。Borderがスケールを維持し、ポルトガルの官僚制度をナビゲートできるのは、これらのエージェントを効果的に構築したからであり、違いを生むのはツールではありません。これらの人々はn8nを使用しています。ただ、それをうまく使う方法を知っているのです。
個人の自動化からチームプロダクトへの転換
このゴルディロックス・ユースケースにいるなら、これが実際のユースケースであることを勇気づけられるべきです。本当に重要です。本当に自動化できます。開発者を待つ必要はありませんが、真剣に取り組む必要があります。
この時点で強調したいことの一つは、コーディング、ソフトウェア、チーム問題のベストプラクティスについて話してきましたが、あなたの個人的な自動化はチームレベルの製品ではないということです。誰もこれについて話しません。n8nは率直に言って、より多くのシートと顧客を獲得するため、個人の生産性としてこれをマーケティングするのが好きです。
あなたのために完璧に機能するエージェントを構築できます。あなたはその癖を理解するかもしれません。ハングした時の再起動方法を知っています。週次でメモリキャッシュをクリアすることを覚えています。10メガバイトを超えるPDFでは失敗することを知っています。
そしてあなたが休暇に行きます。これがあなたのチームが気にかけていた成果物を生産していたことが分かります。あなたのチームは、ワークフローが壊れた時にデバッグできません。なぜ特定の設計決定が行われたかを知りません。何か他のものを壊すかもしれないので、何かを修正するのを恐れています。壁に貼られた怖いスパゲッティのように見えます。
これが自動化プロジェクトが死ぬ方法です。技術的失敗から本当に死ぬのではありません。知識の孤立、サイロから死ぬのです。成功した移行には有用なドキュメンテーションが必要です。文書化と言ったのを覚えていますか、文書化と言ったのは、あなたの自動化があなたのチームの問題だからです。
誰も読まない巨大なマニュアルを作成してはいけません。非常にシンプルで非常に短いランブックを作成するだけです。このエラーが表示されたら、これをチェックしてください。このワークフローはこのWebhookに依存しています。応答時間が劣化するので、毎週月曜日にこのキャッシュをクリアしてください。
パターン、パターン、パターン。創造的である必要はありません。クリーンなパターンを持つ必要があります。理想的には、すべてのワークフローが同じエラーハンドリングパターンに従うでしょう。可能であれば、すべてのエージェントが同じメモリ設定を使用するべきです。退屈ですか？はい。保守可能ですか？まさにその通り。それがポイントです。
チーム問題としてのエージェント自動化
n8nとエージェント自動化をよりチームレベルの製品にするほど、我々の状況は良くなります。ちなみに、これはAI戦略とAI作業における隠れた要石の一つです。通常、Cスイートと個人貢献者に話し、シニアマネージャーやディレクター、チームを運営する人々は、ほとんどの会話から除外されています。
ICと話している時は、暗黙的に彼らがCスイートとリーダーシップだと仮定し、リーダーシップと話している時は、暗黙的に彼らがICと一緒だと仮定します。彼らはどちらでもなく、AI革命にとって重要であり、この種の例はその理由を示しています。
n8n自動化をCスイートの問題にすることはできません。あまりにも高レベルすぎます。しかし、個人貢献者の問題にすることもできません。なぜなら、それは私がここで指摘しようとしているような、あらゆる種類の下流の破綻とワークフローにつながるからです。
それはチーム問題です。つまり、ディレクターの問題であり、シニアマネージャーの問題です。これらのポジションにいるあなた方は、ここで高いバーを主張する人である必要があります。Cスイートがそれをする必要があると言ったからという理由で、マーケターであっても、あなたのチームが自動化に触れ、エージェントを構築する際に、良いエンジニアリング原則の基本を十分に学ぶよう主張すること。それをうまく行い、安価な自動化でそのボックスをチェックすることができますが、後で苦痛の世界を自分に与えることになるから、道を先で苦痛の世界を自分に与えることがないようにしてください。
LLMがn8nにもたらす多方向の加速効果
最後の部分に入りましょう。LLMはn8nにとって複数の方向への加速装置です。第一に、LLMはより多くのことを可能にします。インテリジェンスをワークフローに直接結び付けます。開発者でない多くの人にとって、n8nはインテグレーション経路における最初で最もアクセスしやすい前線を表します。
チャットボットを実際の仕事に結び付けることが実際にできます。必ずしもAPIを使用する必要はありません。効果的にn8nを通じてそれをプロキシしているからです。そこにないふりをするだけでよく、ビジネスを続行できます。そして、人々が実際の仕事を完了したいと思っているので、これは大きなことです。
Slackチャンネルで顧客苦情をモニタリングしたい。緊急度による感情分析を分類したい。Jiraでチケットを作成したい。特定の方法でレコードを処理したい。サポートリードに日次要約を送信したい。これらは全て、チャットボットでは完了できない実際の仕事です。
ClaudeやChatGPT、その他のLLMは、それらのワークフローのJSON設定だけでなく、設計決定とそれらがなぜ行われたか、そしてドキュメンテーションも生成できます。言い換えれば、ワークフロー内のインテリジェンスにアクセスでき、それは加速装置であり、チャットボットとの作業も加速装置です。これは、LLMがあなたを加速させる第二の方法です。
私が話していること、この動画を作成している理由は、8か月前でさえ不可能だったでしょう。n8nは十分に成熟していませんでした。チャットボットも十分に成熟していませんでした。ドキュメンテーションを信頼性を持ってチェックするのに十分良くありませんでした。
今、私たちは成熟している地点にいます。n8nは準備ができています。正しいドキュメンテーションを信頼性を持って引き出すLLMを得ることができます。信頼性のあるワークフローを提供してくれます。良いドキュメンテーションを提供し、チームレベルで機能するエージェントエコシステムの構築を本当に助けるのに十分にスマートです。
これは実際にあなたが思うほど難しくありません。本当に数個のシンプルなワークフローを構築し、それらを徹底的にモニタリングし、エラーをチェックし、そこから拡張することができます。数か月間これを行い、遅く、焦点を当てていたために何をしているかを知っているなら、あなたでもそこまで到達できます。遅いと言いました。この場合、遅いは滑らかで、滑らかは速いです。
滑らかに実装し、一つのエッジケースのみを行うことに焦点を当てていたため、より興味深いことができる地点に素早く到達するでしょう。問題がよく定義され、よく理解しているために、検索拡張生成のような複雑なメモリシステムを使用することが理にかなっている場合もあるでしょう。n8nでそれを行うことができます。人々は直接それに飛び込みます。直接飛び込むことはお勧めしません。
マルチエージェントオーケストレーションを使用できます。複雑なツールチェーンを使用できます。それは全てそこにありますが、そこから始めることはしません。シンプルなものから始めて、時間をかけてそこに到達してください。
真のROIを実現するための原則
ここには実際の節約があります。Vodafoneはn8nワークフローで220万ポンドを節約しましたよね？彼らは大企業です、それが彼らがそこに到達した方法の一部です。しかし、実際のROIは私が話してきた原則から来ることを認識してください。
n8nは、私がAIエージェント構築のために見た中で、同時に最高で、最もアクセスしやすく、最も危険なツールの一つです。今すぐ始めることができるという意味でアクセスしやすいです。この動画を聞く必要さえありません。私がエージェントに情熱を持つ人々と話す実際の状況で何度も何度も見るという意味で危険です。n8nがとてもアクセスしやすかったため、非プログラマーでいて、良いエンジニアリング原則に注意を払わなくても良いと感じて、彼らを燃え尽きさせたのです。
まとめ：規律ある長期的アプローチの重要性
実際のソフトウェアを構築していることを認識し、良い原則に従ってください。シンプルさを強調することを確実にしてください。関心事を分離してください。保守性に焦点を当ててください。可読性に焦点を当ててください。ドキュメンテーションを完了し、LLMと作業し、よく境界設定された問題を解決してください。
あなたの選択は、各アプローチがいつあなたに役立つかを理解し、必要な時にアプローチ間を切り替える規律を持つことです。この特定のエージェントに焦点を当てたアプローチを取る必要があるか、または高い意図、高い思考、慎重なアーキテクチャを必要とする特定の問題に対して2つのエージェントを行うことが理にかなうかどうか。
あるいは、マーケティングに従い、キャンバスに何かを投げ上げて終わりにし、それが機能すると信じることもできます。それはマーケティングでは素晴らしく機能します。デモは問題ありません。時間の経過とともによく持続することはないでしょう。
だから、あなたの選択は、あなたに役立つアプローチで保守可能なソフトウェアを構築することです。時間をかけてスケールする規律を持つアプローチ。複数のエージェントを持てると言ったことを覚えていますか？多分そこから始めない方が良いでしょう。しかし、時間をかけてスケールする規律があれば、そこに到達できます。
または、マーケティングが教えてくれることから始めて、マルチエージェントとRAGと他のすべてを今すぐ行うことができます。魅力は理解します。エージェントは本当にクールです。私もそれらと構築するのが好きです。ただ、ビジネスの長期的価値に役立ち、率直に言って夜よく眠れるように、エージェント構築に時間をかけて取り組んでください。
休暇中にエージェントが壊れたという理由で中断されることを望む人はいません。これが機能すれば、あなたの作業を助けるだけでなく、あなたのチームが実際にエージェントを使用することを助け、それ以上のことを行います。あなたのビジネスがこのエージェントというものが何についてなのかを理解することを助けるでしょう。
だからこそ、私はn8nをある程度危険だと呼ぶのです。これらのエージェントが壊れる時に、企業が理解することが多いのは、AIエージェントは偽物で、AIエージェントは現実でなく、AIエージェントは約束された価値を提供していないということだからです。それは実際には真実ではありませんが、悪く使用すれば真実です。
n8nはナイフのようなものです。ナイフを悪く使用することも、うまく使用することもできます。私はあなたがそれをうまく使用するための原則を提供しようとしています。エージェント構築の幸運を祈ります。あなたなら大丈夫だと分かっています。
コメント