Busabaseで自己改善するAIエージェントを作る：観測・判断・実行の循環

エージェントが仕事を終えても、翌週には同じ背景説明が必要になることがあります。前回はなぜその記事を書いたのか。公開後はどうなったのか。どの提案を見送り、どんな品質を求めたのか。

Busabase で自己改善するエージェントを作るなら、まず三つの段階をつなぎます。Observe → Decide → Act。観測し、判断し、実行する。 実際の変化を読み、AI の分析と人の判断で次の方向を決め、具体的な仕事にします。実行から得られた情報は、次の観測へ戻ります。

このガイドでは、SEO、マーケティングとサポートのメール対応、Google Analytics と Microsoft Clarity から始める製品改善を扱います。各場面で必要な Busabase のノード、フィールド、関連付けも説明します。

一つの目標と三つの段階

何を改善したいのか、どの証拠で進捗を判断するのかを先に決めます。SEO なら、製品の使い方を検索した人に役立つ回答を届けること。サポートなら、繰り返し起きる疑問を解消することが目標になります。

その目標に向けて、三つの段階をつなぎます。

レポートは Decide の中で作る成果物です。 証拠と提案を、人が理解できる形にします。レビューはその段階で行う活動です。 人は前提を直し、品質の基準を高め、提案を見送り、優先順位を変えられます。最終的には実行できる方針、あるいは理由のある「待つ」という判断を残します。

フィードバックは Observe に戻る情報として扱います。流入の変化、ユーザーの不満、新しい要望、顧客の返信、完了したタスクの結果などです。最初の一巡も、すでにあるデータや声から始められます。

ここでいう自己改善は、前回の結果と保存された人の判断を、次の意思決定に生かすことです。人は証拠から判断を磨き、エージェントは記録された選択や基準を後の仕事で使います。実際に効果があったかは、その後の観測で確かめます。

人の判断が循環の方向を決める

中間の段階には、実質的な判断が必要です。このテーマに取り組む価値があるか。回答は十分に具体的か。顧客には別の説明が必要か。今ある証拠で実行に移れるか。

何を重視し、何を優先し、何をよい仕事とするか。その選択に人の判断やセンスが表れます。AI は状況の理解と選択肢の比較を助け、人が方向を定め、エージェントが実行します。

判断のうち、後で役立つ部分を仕事と一緒に保存します。一度限りの選択はレポートやタスクに、繰り返し使う品質基準はワークスペースの Skill に残せます。次回は結果と指針の両方を読みます。

定型的な仕事は、すでに許可された指示に沿って進められます。新しい判断が必要な方針や重要な変更は、人が確認できる状態にします。実行範囲は担当者の指示とワークスペースの権限に従います。

日常の入口はエージェントとのチャット

普段のチャットから、この仕事を進められます。定期実行のエージェントが最新の情報を読み、レポートを作成します。チャット担当が提案を示して意見を求め、人が同意、修正、見送り、追加調査の指示を返します。

その返答を、話し合った具体的な提案に関連付けて保存し、決まった方針を実行タスクにします。実行結果は共有記録に戻り、次の定期実行で読み返されます。

これは三つの役割です。同じエージェントが段階ごとに担当しても、定期分析、対話、実行を分けても構いません。レポートは判断を助ける根拠で、人の返答が方針を定めます。実行は合意した範囲と利用可能な権限に従います。

ノードを役割で組み合わせる

ワークフローごとに一つの **Folder（フォルダー）**を用意します。観測、レポート、判断、タスクは Base（データ表）、目標やサービス方針、品質基準は Doc（文書）、エージェントが繰り返す手順は **Skill（スキル）**に保存します。

レポートの表も Base です。期間や案件ごとに一つのレコードを作り、本文は Markdown フィールドへ、根拠との関連、人の指示、判断状態、日付は別のフィールドへ保存します。チャットで示した提案から、その根拠までたどれるようにします。

表同士はリレーションで結びます。進捗には選択フィールド、対象期間には日付、外部の証拠や成果物には URL を使います。確認した内容、提案の版、日時、利用できる会話の参照も残します。業務上の判断記録と、実際の実行権限は区別して扱います。

データは設定済みの連携、スクリプト、API、エクスポートから取り込み、定期実行はエージェント基盤や自動化ツールで設定します。Busabase は共有記録と変更履歴を保持します。ノードを作るだけでメール、分析ツール、本番公開の仕組みが接続されるわけではありません。

例1：SEO の週次提案から記事を公開する

Busabase の SEO ワークフローでは、分析スナップショット、レポート、目標、Issue キュー、CMS コンテンツを関連付けています。以下はその構造を簡略化した例で、内部画面や実際の経営指標は使用していません。

観測。 定期実行のエージェントが Search Console のクエリとページ別の実績、関連する流入、コンテンツの要望、既存の記事、前回の結果を読みます。新しい回答が必要か、既存ページを更新すべきかを確認します。出典と確定日を残し、比較できる期間を使います。

意思決定。 AI が機会、根拠、確認済みのページ、記事の切り口、優先する理由を報告します。チャットで「この方向で進めて。一つの実際の手順に絞り、模式図を使い、再現できる説明にして」と返せます。エージェントが指示をレポートに関連付け、執筆の要件へ変換します。修正や保留の判断も残します。

実行。 タスクを作成または再利用し、調査、CMS 記事の制作、合意したレビューと公開の手順を進めます。実際の URL と公開状態を記録します。次の観測ではページの状態と、期間がそろった検索データを読みます。公開の完了と、その後の効果は別に確認します。

Busabase でどう構成するか

「SEO 運営」フォルダーに次のノードを用意します。名称とフィールドは、調整できる構成例です。

**関連付け：**報告は観測に、タスクは元の報告に、タスクの出力は CMS レコードか公開 URL に結びます。後日の観測はページと期間を持ち、元の仕事へ戻れるようにします。同じテーマのタスクは安定した識別子で再利用し、毎週重複して作成しません。

チャットでの指示は、「この観測と過去のタスクから週次報告を作り、制作案をここで相談して。私の修正と合意した要件を保存し、許可された公開手順の範囲で実行して、出力を記録して」と書けます。

例2：マーケティングとサポートのメール返信を扱う

返信には、関心の表明、質問、不具合、今後の案内停止の依頼、自動の不在通知などがあります。それぞれ次の行動が異なります。これは構成例であり、特定顧客の導入実績を示すものではありません。

観測。 接続済みのメールサービスから、メッセージ ID、スレッド ID、連絡先、関連キャンペーン、時刻、送受信の向き、原文を保存します。エージェントは過去のやり取り、処理結果、配信状態を読み、人の返信、自動応答、不達を分けます。

意思決定。 AI が意図、根拠、対応案をまとめます。チャットで、言葉遣い、約束できる範囲、次の行動、他の担当者への引き継ぎを判断します。

• **マーケティングの返信：**機能への質問なら、関連する説明やフォローのタスクにします。案内停止の依頼には、作業記録だけでなく、実際の配信サービスの停止状態も更新します。
• **サポートの返信：**操作の質問なら回答タスクに、不具合なら修正タスクに関連付けます。不足する事実は確認し、未確定のサービス上の約束は責任者の判断につなげます。

実行。 決めた方針と既存の許可に沿って返信を準備・送信し、必要に応じてフォローや引き継ぎを作ります。実際の送信状態、送信 ID、内容、連絡先の変更を保存します。次の返信は同じスレッドで扱います。元のメッセージ ID で重複を防ぎ、再試行前に実際の送信結果を確認します。

Busabase でどう構成するか

「メール運営」フォルダーを作ります。

**関連付け：**メールは連絡先へ、分析は元のメールと連絡先へ、タスクは分析とスレッドへ結びます。送信済みの返信はメール表へ戻し、配信状態は連絡先と実際のサービスの両方へ反映します。チャットの提案から原文を開き、実行結果を確認できます。

日次の集計では、繰り返される質問、有望な返信、対応方針の不足も報告できます。一つの会話から得た判断を、次のメール対応に生かします。

例3：GA4 と Clarity の観測から修正・公開へ進む

製品運営では、この循環をコード修正までつなげられます。Google Analytics 4 のファネルデータ探索は、ユーザーがどの段階で先に進めなかったかを調べる手段です。Microsoft Clarity の行動指標には、連続クリック、反応のないクリック、関連するエラーなどの手掛かりがあります。

観測。 GA4 のイベントやファネルの要約、利用できる Clarity のヒートマップや録画から整理した行動の証拠、ユーザーの不満を保存します。証拠の URL と対象期間を残し、実際に使える API、エクスポート、収集手段で取り込みます。両ツールのユーザーやセッションが自然に一致するとは扱いません。

たとえば、特定のブラウザーで重要な操作の離脱が増え、送信ボタンを繰り返し押す様子も観測されたとします。調査の根拠にはなりますが、原因は再現して確認する必要があります。

意思決定。 AI が異常、影響、証拠、考えられる説明、推奨作業を報告します。チャットで担当者が優先順位と期待する体験を決めます。「この環境で再現し、原因を確かめ、ボタンの反応を直して、元の操作を検証して」といった指示を、受け入れ条件のあるタスクにします。

実行。 コーディング担当が証拠とタスクを読み、再現、原因の特定、修正、対象に合った検証、既存の公開手順を進めます。変更へのリンク、検証結果、公開した版、本番での再確認を保存します。修正と公開が許可された範囲なら続けて進め、それ以外の判断はチームのルールに従います。

公開後は元の操作と、イベント取得が正しいかを確認します。その後、比較可能な期間でファネル、同種のつまずき、ユーザーの声を見直します。変更のマージ、公開、問題の解決には、それぞれ証拠が必要です。

Busabase でどう構成するか

「製品体験の改善」フォルダーを用意します。

**関連付け：**分析は観測に、修正タスクは元の分析に、公開と再検証はタスクと版に結びます。後日の観測にも版と期間を持たせます。次回は、未完了の仕事、未検証の公開、解決を裏付ける証拠を区別できます。

一つのフォルダーと一巡の仕事から始める

エージェント入門に沿って接続し、一つの場面を選びます。フォルダーと必要な表、文書、スキルを用意し、既存のリソースは再利用します。

最初は手動で一巡させます。観測を一件残し、分析を作り、チャットで相談し、判断を保存し、一つのタスクを実際の結果まで追います。証拠、方針、タスク、出力をたどれると確認してから、エージェント基盤や自動化ツールで定期実行や新着データのトリガーを設定します。

スキルには次の指示から始められます。Agent Playbooks では、保存された手順をエージェントが見つける仕組みを説明しています。

観測
今回のデータ、要望、ユーザーの声、前回の実行結果を読みます。
出典、日付、集計の定義、重複を確認してください。
目標、サービスや品質の基準、保存された人の修正も読みます。

意思決定
根拠、解釈、不確かな点、次の提案をレポートにまとめます。
元の観測を関連付け、提案をチャットで相談してください。
具体的な提案への同意、修正、却下、追加調査の指示を記録し、
決まった作業方針を保存します。

実行
成果物、担当者、受け入れ条件のあるタスクを作成または再利用します。
合意した範囲で接続済みのツールを使い、実際の出力、状態、
検証や返信の結果、未完了事項を関連する記録へ戻します。

次回の観測では、この結果と人の指示を読んでから新しい行動を提案します。

次の実行が、前回の結果と人の判断を今回の提案にどう使ったかを説明できるかが重要です。証拠が不足していれば、何を待ち、何を補うかを残します。

Busabase の変更リクエストには説明、差分、履歴が残り、権限によって即時マージかレビュー待ちかが決まります。共有ワークスペースが観測と人の判断を保持し、エージェントと接続したツールが実行します。

Busabase で、一つの目標とフォルダー、一つの実際の成果から始めてください。AI が状況を見えるようにし、人が方向と品質を決め、エージェントが仕事にします。その結果が次の循環になります。