5つのAIコアコンセプト
EasyClawを使い始める前に、まず5分だけこれらの概念を理解してください。AIが実際にどのように動いているのかを理解し、ただ闇雲に指示を出すだけの状態から脱却しましょう。
エンジニアになる必要はありません。しかし「AIはなぜタスクを実行できるのか」「どうすればより正確に動くのか」「どんなときにミスが起きるのか」を知っておく必要があります。
1. エージェント（Agent）
初心者向けの理解
エージェント（Agent）は、簡単に言えば「実際に作業してくれるAIの同僚」です。チャットで説明するだけではなく、 あなたのゴールを具体的なステップに分解し、各ステップを完了するたびに次へと進み、最終的に望んだ結果にたどり着こうとします。
AIエージェントの基本概要
一般的なAIエージェントは、多くの場合三つの要素が連携して動きます。
頭脳（理解と意思決定） ＋ ツール／能力（何を使ってどこで実行するか） ＋ 実行ループ（実行しながらチェックする）。
そのためエージェントは「一度に答えを生成する」ようには見えず、むしろプロジェクトの担当者のように、まず考え、次に手を動かし、そして確認をします。
次に、エージェントの動作の仕組みを説明します。エージェントの作業プロセスは、繰り返し実行されるループとして想像できます。 タスクの理解 → 計画の立案 → ツールの呼び出し → アクションの実行 → 結果の検証 → 調整の継続 → 報告。
1）タスクの理解：
エージェントはまず、解決すべき問題、成功基準、制約条件（形式、トーン、時間、できないことなど）を判断します。
情報が不足している場合、質問したり、必要な仮定を立てて説明したりすることがあります。
2）計画の立案（ステップ分解）：
大きなタスクは多くの場合、小さなステップに分割する必要があります。例えば「受信トレイを整理する」は、
メールをスキャン → 種類を識別（通知／請求書／顧客／その他）→ 優先度を判断 → アーカイブ → 返信が必要なら下書き → 一覧にまとめる、
というステップに分けられます。この段階が「何を先に、何を後にやるか」を決定します。
3）ツール／能力の呼び出し：
これこそがエージェントが「実際に行動」できる鍵です。ツールがなければ、文字によるアドバイスにとどまります。
ツールがあれば、ファイルの読み込み、情報検索、メッセージ送信、企業システムへのアクセス、ドキュメント生成など、実際の動作を実行できます。
エージェントが「外部の世界と連携」するのを目にすることになるでしょう。単に一文を生成するだけではありません。
4）実行と記録：
該当するステップで、エージェントは実際に操作をトリガーします（例えば特定のサービスインターフェースを呼び出したり、データ処理を完了させたり、利用可能なコンテンツを生成したり）。
同時に「どこまで進んだか」を記録し、後の続行やロールバックによる修正を容易にします。
5）検証と修正：
エージェントは「一応できたように見える」だけを目指すのではなく、結果が要件を満たしているかどうかもチェックします。
例えば、出力に重要なフィールドが欠けていないか、フォーマット要件に違反していないか、明らかな誤りや不確かな点が含まれていないか、といった点です。
条件を満たさなければ、次のステップを再計画し、反復を続けます。
6）結果の報告と次のステップ：
最後に、エージェントは完了した内容、重要な発見、そして次にあなたの確認が必要な事項を整理して報告します。
何を行ったか、何が完了し、何がまだ進行中かを明確に把握できます。
あなた：「受信トレイを整理して、返信が必要なメールをやることリストにまとめてください。」
エージェントはおそらく次のように動きます。メール一覧を読み取る → 分類してアーカイブ → 送信者／件名／重要な日時を抽出 → 返信が必要なものを判断 →
「やることリスト」を生成（優先度と返信のポイントつき）→ 「これだけの分類が完了したこと、未読や判断保留の項目がどれだけ残っているか」を報告。
ポイント：単なる「整理の考え方」ではなく、使える成果物（リスト／アーカイブ／下書き／進捗）を出力するのです。
初心者はエージェントを普通の会話ツールと混同しがちです。「どうやるの？」と聞くだけ。しかし本来のエージェントには、使える能力と実行フローが必要です。 システムがステップを説明するだけで、結果を出力したり実際の動作をトリガーできないなら、それは「質問応答アシスタント」に近い存在であり、エージェントではありません。 一言で覚えてください：話せる ≠ できる。エージェントの強みは実行とフィードバックにあります。
2. スキル（Skill）
初心者向けの理解
スキル（Skill／能力）は、エージェントが「作業」するために使う具体的な能力モジュールと理解できます。
エージェントは思考と段取り（タスクを受け、次に何をするか決める）を担当し、スキルは「次に具体的にどう動くか」を
実行可能な操作に変えます。資料の検索、文書作成、レポート生成、API呼び出し、計算の実行などです。
スキルがないエージェントはアドバイス止まり。スキルがあって初めてエージェントは実際の成果物を出せるようになります。
スキルの本質とは
エンジニアリングの観点では、スキルは多くの場合「呼び出し可能な能力」であり、次のような形があります。
1）ツール／関数（例：検索、計算、生成、翻訳）
2）ビジネスプロセス（例：注文、経費精算、チケット作成）
3）API呼び出し（例：CRM検索、スケジュール同期、メール送信）。
重要なのは「おしゃべりが上手かどうか」ではなく、スキルにはふつう明確な境界があることです：入力は何か、どう実行するか、出力は何か。
これによってエージェントはタスクをより確実に分解でき、実行後に検証可能な結果を得られます。
エージェントのループには「ツール／能力の呼び出し」というステップがよく出てきますが、 そのステップで呼び出されるのが通常スキルです。エージェントを頭脳、スキルを手足や道具箱とイメージしてください。
もう少し深掘りして、「エージェントのループ内でスキルがどう働くか」を詳しく見ていきます。
1）エージェントが必要なスキルを判断する
タスクが実行フェーズに入ると、エージェントは現在のステップにどのような能力が必要かを分析します。
例えば「ある顧客の過去のコミュニケーション履歴を探す」なら「検索／読み取り」系スキル、
「フォローアップメールの下書き」なら「テキスト生成／テンプレート」系スキル、
「タスクをTODOシステムに同期」なら「書き込み／更新」系スキル、といった具合です。
2）エージェントがスキルにパラメータを渡す（入力）
スキルは通常、特定の入力フォーマットを要求します。例えばキーワード、日付範囲、顧客ID、ターゲットオーディエンス、出力スタイルなどです。
エージェントは文脈からこれらを抽出し、スキルが必要とするパラメータに整形します。
このステップが実行の正確さを左右します。入力が正しくなければ、出力も大きく外れる可能性が高いからです。
3）スキルが実行され結果を得る（出力）
スキルが実行されると、構造化または半構造化された結果が返ってきます。検索でヒットした項目のリスト、計算結果、生成された文書のテキスト、API応答のステータスコードなどです。
これらの結果はエージェントが再び読み取り、その後の意思決定に使われます。
4）エージェントが出力を検証し、次へ進む（クローズドループ）
スキルの実行はゴールではありません。エージェントはさらにチェックします。結果は制約を満たしているか、情報の欠落はないか、再生成や修正が必要か、などです。
満たしていなければ、別のスキル（「追加検索」「文案リライト」「フォーマット整形」など）を呼び出して再び反復することもあります。
これがスキルとエージェントの「協調クローズドループ」です。
初心者はスキルを単なる「チャットの指示」と考えがちです。しかし本来のスキルはむしろ「インターフェース」に近いものです。
入力が明確であればあるほど、出力は安定し、エージェントはそれを頼りに繰り返し実行し、タスクを完了できます。
例えば同じ「メールを生成する」でも、スキルはトーン、長さ、受信者情報、重要な情報フィールドなどを要求します。そうすることで、生成結果が毎回ブレにくくなります。
例：あなたはエージェントに「見込み客へフォローアップメールを書き、タスクを作成して」と頼みました。
これは通常、複数のスキルを連鎖させ、一連のアクションを形成します。
1）顧客情報検索スキル：顧客ID／名前を入力 → 名前、会社、直近のコミュニケーション要点を出力
2）情報抽出／要約スキル：コミュニケーション記録を入力 → 主要な課題と合意済み事項を出力
3）メール生成スキル：トーン（プロフェッショナル／フレンドリー）、テンプレート（フォローアップ／クロージング）、重要ポイントを入力 → メール本文を出力
4）タスク生成スキル：メール内容とアクション提案を入力 → タスク項目（担当者、期限、ステップ）を出力
5）スケジュール／タスク管理スキル：タスクの構造化データを入力 → 作成成功ステータスまたはリンクを出力
お気づきの通り、エージェントはあたかも「営業活動ができる」ように見えますが、その背後ではスキルモジュール群が実際の能力をつなぎ合わせて一つのワークフローを形作っています。 エージェントは、これらの能力を正しい順序で使う役割を担っています。
システム連携を行う多くの人が、スキルを単なる指示文や一行の命令として理解してしまいます。
しかし、明確な入出力と実行可能な仕組みがなければ、エージェントは同じ結果を安定して再現できません。
より正確には、スキルは呼び出し可能な能力ユニットであり、プロンプトはあなたがそれをより適切に「選択／組織化」する助けに過ぎません。
次の三つの質問で素早く判断できます。
呼び出し可能か？
どのような入力が必要で、出力は何か？
実行後にエージェントが使える結果を得られるか（単なる説明ではないか）？
これらを満たすならスキルに近く、そうでなければ単なる「アドバイス型テキスト能力」かもしれません。
引き続きエージェントの「実行ループ」を使ってスキルを理解しましょう。エージェントは思考とスケジュール管理を担い、スキルは具体的なステップの実行を担います。 エージェントがあるタスクに特定の能力が必要だと判断すると、適切なスキルを選び、必要なパラメータを渡して結果が返るのを待ち、 その結果をループに戻して検証、補完、または次の計画に活かします。
例：あなたはエージェントに「顧客へのフォローアップメールを書いて、タスクを作成して」と頼みました。
するとエージェントは異なるスキルを呼び出すかもしれません。
1）顧客情報の検索（名前、直近のやり取りの要点を取得）
2）メール下書きの生成（トーン／長さ／テンプレートに沿って出力）
3）タスク一覧の生成（次のアクションを項目に分解）
これらのスキルが組み合わさって初めて、「非常に仕事ができる」エージェントの振る舞いが生まれます。
スキルはエージェントを「話せる」から「実現できる」へと変え、通常三つの利点をもたらします。
より信頼性が高い（ステップが固定されパラメータが明確）、より制御しやすい（今どのタスクを実行しているか分かる）、より再利用しやすい（同じ能力を別のタスクにも使える）。
スキルを単なる「プロンプト」だと思っている人もいます。実際には、スキルは呼び出し可能な能力モジュール（ツール／インターフェース／プロセス）に近いものです。 明確な入出力と実行方法がないと、エージェントが同じ効果を安定して再現することは難しくなります。
3. プロンプト（Prompt）
一般的な理解
プロンプト（Prompt）とは、あなたが自然言語でAIに伝える「一言の要件」です。 何をしてほしいかを伝えれば、AIはその結果を文章として出力しようとします。
より深い理解
より正確には、プロンプトはあなたとAIをつなぐ中心的なインターフェースです。 エージェントやスキルが組み込まれたシステムにとって、良いプロンプトは単に「テキストを生成させる」だけではなく、 いつスキルを呼び出すべきか、パラメータをどう埋めるか、出力はどのような形か、失敗時にどう処理するかをエージェントに伝えるものになります。
| タイプ | 例 | 効果 |
|---|---|---|
| ❌ 普通のプロンプト | 「メールを書いて」 | AIが自由に生成し、情報不足時に推測しがちで検証が困難 |
| ✅ 優れたプロンプト（実行指向） | 「あなたはB2B営業コンサルタントです。技術責任者向けに製品フォローアップメールを書いてください。トーンはプロフェッショナルかつ簡潔に。 最初にCRMから張三の会社と直近のコミュニケーション要点を読み取ってください。 メールには必ず次の要素を含めてください：1）価値ポイントひとつ 2）直近のやり取りに沿った確認事項二点 3）明確な次のアクション。 出力の末尾には三つのタスクを付記してください（日付形式はYYYY-MM-DD）。」 | トリガー条件が明確 ＋ 呼び出し可能な機能が明示 ＋ 出力構造が検証可能 |
お気づきのように、プロンプトは前述の二つの概念（エージェント／スキル）と同一の動作ロジックの別の側面です。エージェントはプロンプトによってどう動くかを決め、スキルはプロンプトによって何を埋め、どう検証するかを決めます。
「エージェントの作業ループ」は次のように理解できます。
タスクを理解 → 計画を立案 → スキル呼び出しを決定 → スキルが実行 → 結果を検証 → 調整を続行 → 報告。
そしてプロンプトの役割は、各ステップでルールを与え、エージェントがブレたり推測に頼ったりせず、確実にループを回せるようにすることです。
1）プロンプトはまず「目標と成功基準」を定義する（なぜ行うか）
このステップがエージェントの「判定ルール」を決めます。プロンプトでは、解決すべき問題は何か、そしてどのような結果をもって完了とするのかを伝えなければなりません。
例えば「メールを書いて」ではなく、「メールにはどの段落を含めるか、トーンはどうするか、長さの範囲、最後に次のアクションのタスクを記載する」といった具合です。
成功基準のないプロンプトでは、エージェントは「なんとなく似たような出力」をするだけで、品質の検証が難しくなります。
2）プロンプトは「トリガー条件と制約」を与える（いつ、何をするか）
実用的なプロンプトは通常、いつスキルを呼び出すべきか、いつ質問すべきかを明確に記述します。
たとえば、顧客名や日付が不足している場合は、必ず先に尋ねるべきであり、「適当に名前や日付を書く」のは禁じられている、といったことです。
これは不確実性を減らすことに相当します。制約が明確であればあるほど、エージェントは安定します。
3）プロンプトは「どのスキルが必要か、各スキルの入出力の取り決め」を記述する（何を使って行うか）
プロンプトでは次の点を明確にしなければなりません。
呼び出すスキルはどれか、そのスキルが必要とする入力フィールドは何か、その入力はどこから取得するのか、フォーマットは何か。
同時に、スキルの出力をどのような構造で返すべきかも明示します（JSONフィールド、リスト、表、決まった段落構成など）。
このステップこそが、プロンプトを真に「エンジニアリング」する鍵です。「次にどう動くか」を「実行可能な能力呼び出し」に変えるのです。
4）プロンプトは「検証と失敗処理」を要求する（終わったあと、どう正しさを判断するか）
単に結果を生成するだけでは不十分で、プロンプトには検証ルールと失敗時の戦略を書かなければなりません。よくある書き方としては
- スキル呼び出しが失敗した／空の結果しか返らなかった場合：まず原因を診断し（パラメータ誤り／権限／ネットワーク／データ欠損）、その後リトライまたは縮退運転を行う
- 出力に重要なフィールドが欠けている場合：必ず補完するかユーザーに質問し、絶対に推測で埋めない
- フォーマットが合っていない場合：「フォーマット整形スキル／再構成スキル／再生成」をトリガーする
これによりエージェントは「出力を繰り返すが収束しない」というループに陥りにくくなります。
5）プロンプトは「最終的な出力形式」を定義する（誰に使ってもらうか）
最後にプロンプトは、結果をどう提示するかを規定しなければなりません。どのフィールドを必ず返すか、フィールド名は何か、構造化された結果が必要か、
追跡可能な情報を添えるべきか（例：「スキルを呼び出したか、どのスキルか、主要な入出力は何か」）などです。
あなた：「見込み客にフォローアップメールを書いて、タスクを作成して」
もし「実行可能なプロンプト」を使えば、以下の三つが明確になります。
トリガー条件：顧客名／日付が足りなければ最初に尋ねる
スキル呼び出し：最初に「顧客情報検索スキル」、次に「メール生成スキル」、最後に「タスク作成スキル」を呼ぶ
出力検証：メールには価値ポイントの確認と次のアクションを含める。タスクには期限（YYYY-MM-DD）と担当者を必ず含める。
こうすることで初めてエージェントは「それっぽいメールを書く」から「完全で実用的なワークフローを完了する」へと変わります。
多くの人は「とにかくやって」とだけ書いたプロンプトを書きますが、成功基準も入出力の取り決めも失敗処理もありません。
その結果、エージェントは自由に創作し、フィールドが足りなければ推測で埋め、出力の検証が難しくなり、結局あなたも「本当に合っているのか」が確認できません。
正しい考え方はこうです：プロンプトはエージェントと交わす実行契約書のようなものであり、各ステップが判断可能、修正可能、再利用可能になる必要があります。
1）役割と境界を書く：AIに自分が誰か、どんなルールを守るべきかを伝える（「必ず検証してから出力する」「存在しない情報をでっち上げてはいけない」）。
2）形式とフィールドを決める：出力構造を規定する（「JSONを返し、フィールドA／B／Cを含める」または「メールには必ず三つの段落を含める」）。
3）ステップごとにトリガーを書く：タスクを実行可能なアクションに分割し、いつスキルを呼ぶか、いつ質問するか、いつリトライするかを示す。
比べてみてください。「この文書を要約して」 vs 「三つの要点で要約し、各要点は20文字以内とし、最後にキーワードリスト（5語以上）を出力してください」——後者は検証可能・再利用可能で、結果がより安定します。
エージェントは思考と調整を担当し、スキルは具体的な実行を担当し、プロンプトはエージェントに「いつスキルを呼ぶか」「パラメータをどう埋めるか」「結果をどう検証するか」「最終出力の形式は何か」を伝える役割を担います。
4. メモリ（Memory）／ MEMORY.md
一般的な認知
AIのメモ帳：あなたの好みやルールを長期的に保存します。
深い理解
メモリはエージェントの長期記憶の中核です。普通の会話は多くの場合、1回のセッションでしか有効ではありません。 しかしMEMORY.mdに書き込まれた内容は、エージェントが起動するたびに優先的に読み込まれ、 それによってエージェントは「あなたのやり方で」作業するようになり、毎回ゼロから要望を聞く必要がなくなります。
例えば、あなたがエージェントにこう伝えたとします。「簡潔な日本語での返信を好みます。コードはPythonで書いてください。」
この好みが適切な形式でメモリに書き込まれていれば、以降同じ種類のタスクを処理するとき、エージェントはデフォルトでこれらのルールに従います。
あなたは毎回強調する必要がなくなり、「返信のスタイルが毎回バラバラ」という問題も起こりにくくなります。
エージェントを実行役、スキルを道具箱ととらえるなら、メモリはエージェントの長期設定です。
エージェントは起動のたびにまずメモリを読み取り、あなたの好みとSOPを取得し、その後に計画やスキル呼び出しの際にそれらの制約を持ち込みます。
つまりメモリは「実行可能なルール」を長期的に有効にするのです。
メモリが本当に「使える」ものになるためには、これまで説明した三つの基準が必要です。安定したトリガー、明確な入力、検証可能な出力。 言い換えれば、メモリに書き込まれる内容は、エージェントが次にどう動くべきかを具体的に指示できるものでなければなりません。抽象的な感情表現だけでは不十分です。
メモリはこのような「ルールのチェックリスト」形式で書くのがおすすめです。
- 文体の好み：例「日本語かつ簡潔に」「結論を先に」「1段落3文以内」
- フォーマット要件：例「コードはPythonで」「表の出力フィールドはA/B/Cを含める」「日付形式はYYYY-MM-DD」
- 判断のSOP：例「情報が足りなければまず質問し、推測しない。代替案を提示しリスクを明記する」
- 長期的な文脈：例「私のチームはB2Bデリバリー」「よく使うツールはXX（該当する場合）」
「どのように出力してほしいか」を毎回説明するよりも、あなたの仕事の習慣を一度でメモリに書き込んでしまいましょう。エージェントは起動するたびに自動的に従います。
これらのルールを早めに固定すればするほど、後々の手間が省け、一貫性も高まります。
頻度と優先度で整理して書くといいでしょう。高頻度かつ安定しているもの（長期的な好み、決まったフロー）を優先的に書き込んでください。
メモリは下書き置き場ではありません。一時的で一度限りのタスク（例「今日深圳の天気を調べて」）は
絶対に記憶に書き込まないでください。さもなければメモリファイルが次第に肥大化して雑多になり、エージェントが長期的な判断をする際にノイズとなります。
原則：固定された好みと長期的なSOPだけを書き込み、一時的なタスクは無視する。
以下の質問に答えてください。
1）このルールは将来繰り返し使われますか？
2）出力形式／スタイル／実行戦略を安定して変えることができますか？
3）時間が経っても頻繁に変化することはありませんか？
当てはまるほど、メモリへの書き込みに適しています。そうでなければ、今回の会話の指示内に留めておけば十分です。
メモリはエージェントに長期的に一貫した作業方法を形成させます。安定した好みとSOPを固定し、一時的なタスクはその回の実行に留めます。
5. ソウル（Soul）／ SOUL.md
一般的な認知
AIの「性格設定」と行動のボトムライン：エージェントが「どうすべきか、何をしてはいけないか」を決めます。
深い理解
SOUL.mdはエージェントの行動ルール、価値観、操作の境界を定義します。
それはエージェントの「根本の憲法」です——何ができて、何が絶対にできないかを、ここに明記します。
したがってソウルは単なるスタイルの好みではなく、エージェントの安全境界とコンプライアンス出力に直接影響します。
メモリが「何を覚えているか」なら、ソウルは「どのようなAIになるか」を規定しています。 例：製品関連の質問のみ回答する。財務操作は必ず二重確認する。パスワードや機密情報の要求を禁止する。 法律／医療に関わる場合は免責事項を表示し、人間／専門チャネルへ誘導する、など。
SOUL.mdの設定は、高リスクシナリオにおけるエージェントの「拒否の仕方」や「代替パス」を直接的に決定します。
チームツールとして展開する場合や企業データを扱う場合、ソウルの設定が不適切だと、権限の逸脱、境界の侵犯、コンプライアンスリスクを引き起こす恐れがあります。
したがって本番稼働前に必ずしっかりとこのファイルを設定し、テストケースを用いて境界が有効に機能するか検証してください。
ソウルは「実行可能なルールのチェックリスト」として書くことをおすすめします。以下のような項目をカバーしてください。
- 許可されること：エージェントの作業範囲と領域の境界（例：製品問い合わせ／内部プロセスのみを処理する）。
- 禁止されること：高リスク行為の明確な拒否（例：パスワード／キーの要求、不確実な結果の約束、権限のバイパス）。
- 確認が必要なアクション：送金、返金、契約、権限変更など、二重確認または承認プロセスを必要とするルール。
- 出力方法とトーン：例：丁寧であること、個人攻撃をしないこと、脅迫的な表現を使用しないこと。
- 境界に直面した場合の対処方法：完了できない場合の代替案の提示（例：記録して人間に引き継ぐ／専門部門への相談を提案）。
あなたが会社のためにカスタマーサポートエージェントを設定したとします。そのSOUL.mdには以下の内容が含まれるかもしれません。
• 常に礼儀正しく、誹謗中傷や否定的なレッテル貼りは使用しない
• 返金や賠償を約束しない。「記録して担当に渡します／専門部署に回します」とのみ伝える
• 法律関連の質問には、一律で「法務部門／専門家にご相談ください」と返答する
• パスワード、認証コード、秘密鍵を求められた場合：直接拒否し、正規の手続きで確認するようユーザーを誘導する
このように設定しておけば、ユーザーがどのように誘導しようとしてもエージェントはラインを越えません。
ソウルを修正した後は、いくつかのテスト質問で検証することをおすすめします。「拒否すべきもの」「確認が必要なもの」「正常に応答できるもの」に分けて確認してください。
6種類のテスト質問を用意して、ソウルが機能しているか検証できます。
1）専門領域外の質問：エージェントは拒否するか、または適切な誘導を行うか？
2）高リスク要求：明確に拒否するか？
3）二重確認が必要なアクション：実行前に確認を取るか？
4）機密情報の要求：拒否し、安全な代替フローを提示するか？
5）コンプライアンス／免責事項：ルール通りに出力するか？
6）「権限の抜け道探し」：ユーザーがフローをスキップするよう求めても、境界を守り続けるか？
SOUL.mdはエージェントの「ボトムラインと境界」を決定します。それによってAIは実行時に原則を持ち、予測可能になり、 チームやビジネスシーンにおいてより安全で信頼性の高い存在になります。
応用概念（オプション）
以下の三つの概念は、あなたをより「自動化に詳しい」にしてくれます。これらはまったく新しい知識ではなく、 これまで話してきたエージェント／スキル／メモリ／ソウル／プロンプトという一連の動作ロジックを、 実際に「動かし、つなぎ、安定して統合する」レベルに落とし込むものです。 初心者は最初はスキップしても構いません。マルチステップのフローを作り始めたり、外部サービスと連携させたり、データ受け渡しの問題を調査するときにまた戻ってくると、非常に時間の節約になります。
🔀 1）ワークフロー（Workflow）
ワークフロー（Workflow）は、再利用可能な実行ルートです。複数のステップをつなげて、システムが順番に一つのゴールを達成するようにします。 エージェントを「考えて実行する同僚」とするなら、ワークフローは「その同僚に割り当てられたタスクキューとつなぎ方」です。 一言で完了できないタスクを、どのように安定して多段階のチェーンとして実行するか、という問題を解決します。
一般的なワークフローには、多くの場合次の要素が含まれます（この考え方でEasyClawのマルチステップ機能を理解できます）。
- ステップリスト：ステップ1で何をするか、ステップ2で……と各ステップの責務範囲を明確にします。
- 入力と出力：各ステップは単なる「テキストの説明」だけでなく、次のステップで利用可能な構造化された結果を生成する必要があります。
- 条件と分岐：例「重要なフィールドが不足している場合はまず質問／追加検索」、そうでなければそのまま次のステップへ。
- 検証と失敗処理：例「解析に失敗したら再試行するか、フォールバック案に切り替える」。
- 集約出力：最終結果を、利用可能な形式で提供します（リスト、レポート、タスク一覧、通知内容など）。
ワークフローと前述の概念との関係は？一文でまとめられます。
エージェントは意思決定と調整を担当し、スキルは具体的な実行を担当し、メモリ／ソウルは長期的なルールと境界を担当し、プロンプトは「どうやるか」を伝え、
ワークフローはこれらのステップを順番にチェーン化します。
例：「ユーザーの苦情をチケットにエスカレーションし、担当者に通知する」を完了したい場合。 合理的なワークフローは次のようになるでしょう。
- 入力の収集：フォーム／メッセージから苦情内容、ユーザー情報、タイムラインを取得。
- 情報抽出：エージェントを使用して苦情の要点を構造化（例：問題の種類、影響範囲、重要な時点）。
- ルール判定：ソウル／ルールに基づき、高優先度かどうか、エスカレーションすべきか、さらに情報を収集すべきかを判断。
- チケット作成スキルの呼び出し：構造化されたフィールドをチケットシステムインターフェースに入力し、チケット番号を生成。
- 通知スキルの呼び出し：チケット番号、要約を担当者に送信（Feishu／メール／IM）。
- 結果の検証：チケット作成が成功ステータスを返したか、通知が送信されたかを確認。
- 集約フィードバック：ユーザーまたは管理者に「チケット作成済み ＋ リンク／番号 ＋ 次の処理提案」を出力します。
お気づきでしょう。ワークフローが解決するのは「説明文の書き方」ではなく、「複数のツール呼び出しと検証ステップを確実につなげる方法」です。 複雑なプロセス（特にクロスシステム：IM ＋ チケット ＋ データベース）を構築し始めると、ワークフローは最も頼りになる機能になります。
📦 2）JSON（データ交換形式）
JSONはエージェントと外部ツール、APIの間でデータを受け渡すための標準形式です。 マルチステップ自動化において、JSONの役割は非常に重要です。「次のステップで正しいデータを取得できるか」を検証可能な問題に変え、 「直感で自然言語を読み解く」ことから脱却させます。
JSONはシステム内部の「構造化データパッケージ」と理解できます。中身は散漫な文章ではなく、明確なフィールドと型です。例： チケットタイトル、ユーザーID、優先度、期限、通知内容など。
EasyClawのワークチェーンにおいて、JSONは通常以下の場所に現れます。
- スキルの入力と出力：スキルは多くの場合、特定のフィールドを入力として必要とし、エージェントの意思決定のために構造化された結果を返します。
- API呼び出しパラメータ：例：Feishuインターフェースを呼び出す際、パラメータはフィールドごとにJSONに整理する必要があります。
- ステップ間のデータ受け渡し：ワークフローのあるステップの出力JSONは次のステップで読み取られます。
では、なぜ多くの問題が「エージェントができないように見える」のに、実はJSONが原因なのでしょうか？ よくあるケース：
- フィールド名の不一致：例：期待する入力が
user_idなのに、実際にはuserIdが渡された。 - フィールドの欠落：例：必須フィールドが欠落しており、インターフェースがエラーを返す。
- 型の不一致：例：日付が文字列であるべきなのに数値で渡された、または配列であるべきなのにテキストが渡された。
- JSONフォーマットエラー：引用符の欠落、括弧の不足、末尾の余分なカンマなどにより、解析に失敗する。
そのため、統合問題を調査する最適な順序は通常：最初にJSONを確認し、次にプロンプト、最後にエージェントの判断ロジックを確認するです。 なぜならJSONは「動作するかどうか」の基盤だからです。
🔑 3）APIキー（アクセスキー）
APIキーはAIモデルやサードパーティサービスにアクセスする際の認証情報です。 正しいAPIキーがないと、システムは通常対応するモデルやサービスを呼び出せません。エージェントの推論がどれほど優れていても、「実行できない」状態に留まります。
EasyClawのシナリオでは、2つのケースを区別する必要があります。
- デフォルトで公式機能／ポイントを使用する場合：初心者は通常、自身でキーを用意する必要はありません。プラットフォームが既に接続を完了しているためです。
- カスタムモデル／カスタムサービスに接続する場合：対応する場所にAPIキーを入力し、該当するエージェント／スキルをそのモデルに向ける必要があります。
APIキーは「使えるかどうか」だけでなく、「どの機能を使うか、コストと安定性」にも影響します。
- モデルの選択：異なるキー／異なるモデルは、異なる推論品質、速度、出力形式のパフォーマンスをもたらす可能性があります。
- コスト管理：一部のプラットフォームでは使用量に応じて課金され、キーに対応するアカウント／クォータが利用可能なコストに影響します。
- 権限の境界：一部のサービスのキーは限られたインターフェース呼び出ししか許可しない場合があり、特定のスキルの実行が失敗する可能性があります。
「スキル呼び出しの失敗」を調査する一般的なアプローチ：キーが正しく入力されているか、キーの有効期限切れ／クォータ不足か、そのキーに呼び出し権限があるか。 APIが認証エラー（401／403系）を返す場合、まずAPIキーの設定問題を疑います。
いつこれらを真剣に確認すべきか？（クイックリファレンス）
- マルチステップ自動化を行いたい場合：ワークフローがチェーンを安定して実行できるかを決定します。
- Feishu／企業システム／外部インターフェースに接続したい場合：JSONがデータを正しく受け渡せるか、解析できるかを決定します。
- 独自のモデルやカスタムサービスに接続したい場合：APIキーが該当機能を呼び出せるかを決定します。
- 「説明できるが実行できない」または「実行失敗の原因がわからない」場合：通常、ワークフローの連携、JSON構造、APIキー権限の3か所を順に調査するのが最も早いです。
ワークフローがステップを順番に確実に実行させ、JSONが各ステップで渡されるデータ構造を正しく利用可能なものにし、 APIキーがツールとモデルを本当に呼び出せるようにします。この三者がそろうことで初めて、あなたの自動化は「賢そうに見える」から「実際に現場で使える」ものへと変わります。
エージェント ＝ 実行力のあるAI同僚
スキル ＝ 呼び出し可能な機能モジュール（ツール／インターフェース／プロセス）
プロンプト ＝ エージェントに実行方法を伝える（ルール、トリガー、出力、失敗処理）
メモリ ＝ 長期的な好みとSOP（ルールを長期的に有効化）
ソウル ＝ 行動憲法と境界（許可／禁止／確認ポリシー）
ワークフロー ＝ マルチステップリレーの実行ルート
JSON ＝ 構造化データ交換形式（フィールドの可用性を保証）
APIキー ＝ サードパーティ／モデル接続認証情報（機能の呼び出し可能性を保証）