AIバブルの議論の先へ：企業はAIで何を実現できるのか――Busabaseチームの7つの実践

モデルの能力は上がり、AIへの投資も拡大しています。その一方、企業の責任者が知りたいのは、もっと具体的なことです。ツールを契約し、モデルをつないだ結果、どの仕事が改善したのでしょうか。

「AIバブル」は、現在の企業評価や投資額を、将来の需要・売上・利益で支えられるのかという議論です。AIで役立つ仕事ができるかとは関係がありますが、同じ問いではありません。有用な技術の周囲で過剰投資が起きることもあれば、見事なデモが社内の成果につながらないこともあります。

日々の業務に戻ると、確認すべきことが明確になります。記事は公開まで進んだか。レポートの提案は誰かが引き継いだか。コードの完成後、誰が受け入れを判断したか。

Busabaseチームは、自らのコンテンツ制作や運営、共同作業にAIを使っています。以下は実際の社内記録に基づく7つの実践です。完了した工程と、人の判断が必要な部分をあわせて紹介します。

共通する進め方：観察、判断、実行

7つの仕事は、観察 → 判断 → 実行 → 次の観察という小さな循環で捉えられます。データ、依頼、利用者の声、前回の結果を読み取り、エージェントが分析と提案をまとめます。人が判断、品質へのこだわり、優先順位を加え、実行した結果を次の回で確認します。

普段の入口は、接続済みエージェントのチャットで構いません。提案に対して「方向性は賛成。ただし先に根拠を補って」「この基準で進めて」と伝えると、エージェントがその意見を対象の提案と関連付け、タスクを更新します。レポートは判断材料で、レビューはその活動の一部です。実行できる範囲は、既存の許可と実際の権限に従います。

以下では、すでに行った実践を残しつつ、読者が試せる最小構成の例を添えます。表名、項目、会話は説明用に簡略化しています。図は架空のデータを使った製品風のUIイメージであり、社内画面、実績の証拠、内部スキーマの完全な公開ではありません。

ワークスペースを準備する

まずエージェント入門に沿って、普段使うエージェントを接続します。関連資源はフォルダーにまとめ、既存の表を再利用します。**Base（データ表）**には型付きの記録、**Doc（文書）**には目標・方針・品質基準、Skillには繰り返し使う手順を保存します。レポート表もBaseです。本文をMarkdown項目に、期間・出典・判断・タスクとの関連を個別の項目に置けます。

表同士は関連フィールドで接続します。期間には日付、進捗には選択肢、指標には数値、証拠にはURLや添付を使います。一度限りの判断はレポートやタスクへ、繰り返し適用する基準は文書やSkillへ残します。

外部データには接続済みAPI、エクスポート、収集ツールが必要です。実行はエージェントとツール、定期起動はスケジューラーが担います。ノードを作るだけで分析サービスへの接続、メール送信、デプロイが始まるわけではありません。最初は手動で一巡させてから定期化します。

01 多言語の記事を、執筆完了から正式公開まで進める

1本の記事に5言語の版があり、本文、表紙、修正指示が別々の場所にあると、編集の承認後にも仕事が残ります。最終版を探し、登録し、日付を確認し、公開結果を検査する工程です。

直近の一括公開では、25本、計125言語版の承認済み本文と画像をBusabase CMSへ登録しました。1本ごとに5言語版を1つのChangeRequestにまとめて提出・マージし、正式レコードを読み戻して本番URLを確認しました。125件すべての直接リンクが正常な応答を返しました。

そのうち4本は、以前の作業を後日納品したものでした。関連する元の日次レポートに戻って日付を確認し、納品日にまとめることなく、当初の2日間に割り当てました。作業の根拠、最終原稿、公開記録が対応している必要があります。

エージェントが担当したのは、許可後のアップロード、提出、マージ、確認です。見出し、本文、ビジュアルの公開可否は編集責任者が判断しました。URLの正常応答だけで、内容の質や読みやすさまで確認できるわけではありません。

残ったのは、公開記事、各言語版、画像、変更履歴です。後日、事実や画像を直す場合も対象を特定できます。

図を原寸で開く

Busabaseでの組み立て方

「コンテンツ納品」フォルダーに3つの表を用意し、編集・公開基準の文書と多言語納品のSkillを添えます。

チャットでの依頼例：

この記事の各言語版を確認し、本文・表紙・日付の根拠に不足があれば一覧にしてください。未決事項をここで示し、私が確認した範囲で更新を提出してください。公開後は全ページを検査し、この納品に結果を関連付けてください。日付が不明なら出典を調べ、今日の日付に置き換えないでください。

納品記録に不足を並べ、確認後に各CMS版と検査結果を結びます。画像が壊れていれば失敗項目と修正タスクを残します。次の実行は未完了項目を引き継ぎます。URLの正常応答だけでは、本文と画像が正しいことまでは確認できません。

02 検索トレンドを、答える価値のある問いにする

「AI bubble」も、その一例です。チームの検索レポートは米国での短期的な関心を記録し、中国や「バブル崩壊」の意味に関する関連検索も確認しました。

キーワードを見出しに入れて、すぐ製品紹介へ進むと、読者の関心から離れかねません。検索している人は、企業評価、投資回収、あるいは特定の報道を理解したいのかもしれません。

実際の調査記録では、この語は当初、観察対象でした。関心の高まりはあっても、元の出来事や独立した読者の問いが未確認だったため、自動で執筆タスクにはしませんでした。編集者は、報道の解説、投資リスクの分析、企業での利用経験のうち、読者が何を求めているかを見極める必要があります。それぞれに必要な資料は異なります。社内の実践は利用経験を示せますが、産業の評価額を論じるには市場や財務の証拠が必要です。

チームはBusabaseで、検索観測、キーワード、対象の問い、既存ページ、実行タスクを関連づけています。選ばれたタスクから元のレポート、内容の不足、受け入れ条件を確認でき、見送った語にも理由が残ります。

まず確かめる結果は、トレンドが有用な問いになったか、その問いに対応する成果物ができたかです。流入や事業への効果は公開後も追跡します。

図を原寸で開く

Busabaseでの組み立て方

「検索企画」フォルダーに、読者の問いと記事の守備範囲を示す文書、調査・執筆のSkillを置きます。

チャットでの依頼例：

今週の検索観測と既存記事から、読者が知りたいことを整理してください。根拠不足の企画は観察に残し、書く価値のある案を1つ示してください。切り口を確認した後に関連タスクを作り、完成記事と後日の検索状況を書き戻してください。

「元の出来事を確認するまで執筆しない」という判断も有効です。その場合のタスクは調査になります。執筆を決めた後は、観測→判断→タスク→記事をたどれます。次のレポートは同じ企画キーで既存タスクを探し、納品と公開後の反応を別々に確認します。

03 SNSの数字を評価する前に、どの投稿かを確定する

再生数がよさそうなスクリーンショットだけでは、振り返りには不十分です。どのアカウントの投稿で、公開日と計測日はいつか。保存数がゼロの場合と、取得できていない場合でも、次の対応は変わります。

チームはBusabaseに、アカウント、投稿、指標、取得元の状態を分けて保存しています。実際の投稿レコードには、プラットフォーム上の識別情報、公開URL、公開日時、取得できる再生・反応指標と、その出所・更新時刻が含まれています。

エージェントは特定の投稿を軸にデータを整理し、運営担当者は記録に戻って確認できます。同じテーマを複数の媒体に展開した場合も、各媒体の値を別々に扱い、異なる指標を見栄えのよい合計へ混ぜません。

全項目がそろうとは限りません。公開リンクがなければ補完待ち、指標が読めなければ未取得として残します。それを踏まえて、追加調査、表現の変更、継続観察を判断します。

実現したのは、識別できる投稿と確認可能な実績の対応です。再投稿、内容変更、広告出稿には判断と権限が必要です。

図を原寸で開く

Busabaseでの組み立て方

「SNS運営」フォルダーに、媒体別の指標定義を記した文書と収集・振り返りのSkillを置きます。

チャットでの依頼例：

この投稿群のアカウント、公開URL、収集日時を確認してから振り返ってください。未取得とゼロを分け、媒体ごとに比較してください。私の確認後、元スナップショットに関連するデータ補完や内容改善のタスクを作ってください。

「保存数が未取得」なら収集確認のタスクにし、「保存した人がいない」とは解釈しません。媒体と投稿IDで作品を識別し、収集日時でスナップショットを区別します。修正版や再投稿も対応する作品に結び、次回は同じ定義と比較可能な期間で評価します。

04 顧客とパートナーの関係を確認し、引き継ぎの誤りを防ぐ

同じ名前が複数の業務資料に登場することがあります。見込み顧客か、協業相手か。名前だけで統合すると、その後の対応を誤る原因になります。

実際の社内整理では、責任者がある連絡先をパートナーだと確認しました。それを受けて分類を修正し、確認の根拠と、所属組織や役割分担などの不足項目を残しました。修正を新しい商談として扱わず、同名の顧客レコードとも自動で統合していません。

エージェントは許可されたやり取りから要点を整理し、不足項目や変更案を準備できます。本人の同一性、取引条件、約束、次の予定は、根拠を持つ人が確認します。

成果物は、次の担当者が使える関係記録です。関係性、確認済みのこと、未確定のことがわかり、チャットから事情を再構成する必要を減らせます。

最初から全自動の営業システムを作る必要はありません。一度のやり取りに含まれる事実と未確認事項を分けることから始められます。

図を原寸で開く

Busabaseでの組み立て方

「顧客・パートナー連携」フォルダーでは既存の連絡先を再利用し、関係確認・引き継ぎの基準文書と整理のSkillを添えます。

チャットでの依頼例：

今回のやり取りで連絡先資料を確認し、事実・推測・不明点を分けて修正案を見せてください。この人はパートナーです。その分類だけを直し、組織と役割の不足は補足タスクにしてください。他の同名レコードは統合しないでください。

連絡先の分類、判断の記録、不足を埋めるタスクが成果になります。同一人物だと確かめられなければ未確認に残します。後日のやり取りは元タスクを更新し、資料訂正を新しい会談や商談として数えません。

05 開発の「検証済み」に、確認できる証拠を添える

AIによるコード作成が速くなっても、要件を満たすか、重要な画面が動くか、どの条件を検証したかという確認は残ります。完了通知だけでは、受け入れの判断材料が足りません。

チームはBusabaseで、コード変更、課題、受け入れ記録を整理しています。実際の記録には合格の結論と証拠画像があり、対象の作業に戻って判断の根拠を確認できます。

エージェントはチェック項目の準備、許可された検証、失敗と結果の整理を担当できます。確認者は、その証拠が要件を覆っているか、追加テストが必要かを判断します。合格は検証した範囲に限られ、リリースやデプロイにはそれぞれの許可が必要です。

証拠の置き場所が定まると、不具合が再発したときに以前の確認内容を見直し、漏れた条件を次の検査に追加できます。

図を原寸で開く

Busabaseでの組み立て方

「開発納品」フォルダーに表をまとめます。期待する動作と検査範囲は受け入れ・公開基準の文書へ、再現・検証・書き戻しの方法はSkillへ保存します。

チャットでの依頼例：

この課題を完了条件に沿って、許可された環境で再現・修正してください。シナリオ、結果、証拠を関連する受け入れ記録へ保存し、確認範囲と不足をここで説明してください。確認済みの公開範囲で進め、配備版と本番再確認を記録してください。

例えば「送信失敗後にボタンを再び使えるようにし、理由を示す」というタスクなら、対象版と実際の操作証拠が必要です。検査失敗は元タスクへ戻し、配備後の再確認は別に残します。再発時には未検査の環境や手順を追えます。「合格」の項目が公開権限を与えるわけではありません。

06 製品週報で、登録後に何が使われたかを問う

新規登録数だけで週報を終えると、肝心な問いが残ります。利用者は価値のある最初の操作を完了したか。どこで止まったか。次に直すのは集客か、使い始めの導線か。

チームの製品週報は、登録と利用行動をあわせて分析し、集計期間、出所、その後の判断を保存しています。実際の週報でも、新規獲得と継続する利用の間にある差を指摘し、登録数だけを成長の成果として扱っていません。

比較条件も確認します。前回公開したスナップショットと今回の比較期間が一致しなければ、どの値が方向感の参考にとどまるかを説明し、厳密な前期比較とは分けます。

エージェントは確認可能な数値と分析を準備します。目標、優先順位、資源配分は事業責任者が決めます。次の週報では行動が実施されたか、問題が変化したかを追えます。

成果物は、次の問いにつながる週報です。責任者は、その記録を基に次の行動を話し合えます。

図を原寸で開く

Busabaseでの組み立て方

「製品運営」フォルダーに指標定義・製品目標の文書と、データ読取・報告・タスク化・再確認を担うSkillを置きます。

操作の流れにはGA4のファネルデータ探索、連続クリックなどの手掛かりにはClarityの行動指標を使えます。原因は実際の操作で確かめます。

チャットでの依頼例：

今週の登録と重要操作を、接続済みのGA4要約、Clarityの証拠、利用者の声と合わせて見てください。集計定義と欠けた情報を説明し、使い始めの改善案を1つ示してください。確認後に調査か修正のタスクを作り、来週は配備と元の問題の解消を先に確認してから行動変化を比較してください。

離脱や連続クリックは調査の手掛かりです。まず調査する判断を保存し、開発エージェントが再現してから修正の要否を決めます。異なる分析基盤の利用者やセッションを無理に対応させません。週報を観測とタスクに結び、追跡期間には配備版も残します。未着手、公開済み未検証、改善の根拠ありを区別できます。

07 修正をSkillに残し、次の実行で読み込まれたかを確かめる

ある会話でエージェントがルールを理解しても、次の会話に自動で伝わるとは限りません。説明を繰り返す負担も、新しい指示を読まずに同じ失敗をする可能性も残ります。

チームは一部の作業方法をBusabase上のSkillとして維持しています。自動タスクの開始時に現在の方法を読み込み、実行記録に読み込み情報を保存します。結果がおかしいときは、どの版に従ったかを調べられます。

実際には、方法は更新されてもタスクの入口に古い指示が残ることがありました。文書の修正だけでは終わらず、その後の実行が新しい版を読み、要求どおり動いたかを確認する必要がありました。

方法、版、実行入口、実行結果が点検できる対象になります。有効な手順は再利用でき、失敗した部分は直せます。Skillごとの権限とレビュー条件は引き続き必要で、再利用によって権限が広がることはありません。

企業でも、繰り返す仕事を1つ選び、入力、手順、例外、受け入れ条件を記述し、別のエージェントへ渡して成果物を確認するところから始められます。

図を原寸で開く

Busabaseでの組み立て方

「仕事の手順」フォルダーでは、再利用する方法と実際の実行を分けて保存します。

チャットでの依頼例：

この訂正を作業手順の修正案にし、失敗例を残してください。私が確認した方針でSkillと対象タスクの入口を更新し、次回は現在のSkillを読んで版か内容ハッシュを記録してください。同じ例で結果を確認し、「覚えました」だけで終えないでください。

「Skillを更新した」は途中経過です。改善記録から変更を開き、新版を読み込んだ実行と成果物の証拠までたどれる必要があります。入口に旧指示が残れば直して再検証します。まず1つの定期タスクで試し、完了条件を満たしてから他へ広げます。

AIの価値は、実際の仕事で検証する

7つの実践にも、未回答の問いは残ります。記事は有効な訪問につながったか。情報整理は確認負担を減らしたか。開発の証拠は受け入れを速めたか。引き続き測定が必要です。

それでも、具体的な工程は進んでいます。記事は公開され、検索語は根拠ある選題判断へ進み、投稿と指標が対応し、業務上の関係や検証証拠を確認でき、週報は利用を問い、方法は実行をまたいで保守できます。

企業の最初の検証には、入力が比較的明確で、受け入れ責任者がいる反復業務が適しています。成果物を決め、1回実行し、別の同僚へ渡してみる。実行・確認時間、手戻り、採用状況、事業結果を記録してから、投資を広げるか判断できます。

Busabaseは、データ表、文書、Skill、AirAppをチーム共通のワークスペースにまとめます。エージェントはSkill、MCP、CLI、APIから接続し、書き込みには変更履歴が残ります。重要な変更を人の確認まで待たせ、同僚や次のエージェントがその記録から仕事を続けられます。

まず役に立つ一巡を試す

1つの場面を選び、上の構成で入力を1件保存し、エージェントに提案を1つ依頼します。チャットで実際の取捨選択を伝え、タスクを結果まで追います。元の根拠、人の判断、成果物、次回読むべき記録がつながっているか確認してください。

定期実行まで詳しく組み立てたい場合は、Busabaseで自己改善するエージェントを作る方法も参照できます。同じ循環をSEO、メール、製品運営に当てはめています。一巡の納品と引き継ぎを確認してから、投資を広げるか判断できます。