朝8時、AIエージェントが問い合わせの正本となるCRMを読みます。検索流入が増えていても適格問い合わせが増えていなければ、記事本数ではなく導線かオファーを疑う。最大の詰まりを一つ選び、次の4時間で変更と検証まで進めます。
昼12時にはコードを直し、テストと実ブラウザで動作を確認。夕方16時に公開結果を読み戻し、夜20時には続ける施策と止める施策を組み替えます。Heygoodが自社で続けている開発運用です。
朝の選択、昼の実装、夜の再計画で回す1日の実行サイクル
どの仕事をAIエージェントへ任せているか？
調査、計画、実装、検証、記録を一つの流れで任せ、外部送信や契約判断は人に残しています。
AIエージェントへ渡すのは目的に向かって証拠を集め、変更し、結果を確かめる一連の仕事です。「競合を調べる」「記事案を書く」といった作業名だけでは渡しません。何を増やしたいか、どの数値を正本にするか、どこまで変更してよいかを先に決めます。
現在の運用では問い合わせ、資料取得、商談履歴をbiz platform CRMで確認します。GA4のイベント数だけを成果にせず、CRMで適格と判定された問い合わせをNorth Starへ加算する設計です。
AIエージェントが進める仕事と、人が決める判断の境界
| AIエージェントへ任せる仕事 | 人が判断する仕事 |
|---|---|
| 現在値と前回差分の確認 | North Starの変更 |
| 最大の詰まりを一つ選ぶ | 広告費、契約、料金の決定 |
| 記事、導線、計測、コードの変更 | 個人情報を含む外部送信 |
| テスト、ビルド、実ブラウザ確認 | 法務表現と実績表現の承認 |
| 証拠と次の観測値の記録 | 破壊的変更とDBスキーマ変更 |
任せる範囲の考え方はAIエージェントにどこまで権限を渡してよいかで詳しく整理しています。
4時間の一回で何を完了させるか？
一回の枠で最大の詰まりを一つ選び、変更を一件完成させ、証拠と次の観測値まで残します。
一回の枠で記事、CTA、フォーム、CRMを同時に触ると、数値が動いても理由を追えません。そこで対象を一領域へ限定します。検索流入が詰まりなら記事、フォーム開始後の離脱なら入力画面、保存失敗ならCRM連携だけを扱います。
4時間で一件の変更と次回に使える証拠を残す流れ
| 段階 | 4時間枠で残すもの | 終了時の確認 |
|---|---|---|
| 観測 | 前回からの差分 | 古い数値を流用していないか |
| 選択 | 最大の詰まり一つ | 他の領域を同時に触っていないか |
| 実行 | 公開可能な変更一件 | 変更が目的へ直接つながるか |
| 検証 | テスト、画面、計測の証拠 | 成功条件を満たしたか |
| 記録 | 次回観測値と中止条件 | 次の担当が同じ判断を再現できるか |
調査だけで時間を使い切った場合も、記事構成、設定案、検証手順など承認後すぐ動かせる成果物まで仕上げます。状況報告だけで終わらせません。
エージェントと人の境界をどう決めているか？
公開、個人情報、契約、料金、法務表現、破壊的変更を人の承認対象として先に分けています。
人の承認は最後に足す安全装置ではありません。作業を始める前に、AIエージェントが止まる場所として決めます。通常の記事修正やテストは進めても、未レビュー記事の検索公開、顧客への一斉送信、DBスキーマ変更では止まる設計です。
AISIの評価観点ガイド第1.20版ではAIエージェントの自律的な挙動と外部環境との相互作用について、観測と制御を評価観点に置いています。Heygoodでも「正しい文章か」だけでなく、何を変更し、どこで止まり、誰が承認したかを追います。
何を見て次の施策を変えるか？
CRM、公開サイト、検索、行動ログ、Gitを読み、問い合わせから最も遠い詰まりを一つ選びます。
問い合わせ数が0件でも、すぐ記事を増やしません。検索表示がないのか、記事へ来てもCTAを押さないのか、フォームを始めても送らないのか、送信後にCRMへ残らないのかで打ち手が変わります。
問い合わせまでの数字が落ちた場所から次の施策を決める経路
| 観測する場所 | 分かること | 次に選ぶ施策の例 |
|---|---|---|
| GSC | 検索表示、クリック、検索語 | 記事の新規制作、タイトル修正 |
| GA4 | 記事閲覧、CTA、フォーム | 導線とオファーの変更 |
| Clarity | スクロール、迷い、誤操作 | 画面構成と入力負担の変更 |
| biz platform CRM | 適格判定、商談化、流入元 | 対象読者と施策配分の変更 |
| Git・公開URL | 何を変え、何が公開されたか | 継続、修正、停止の判断 |
画面のクリック数と営業成果を同じ箱へ入れないことが前提です。資料取得も問い合わせと分け、資料を読んだ人が後日相談したときだけ、同じCRM上で関係を確認します。
実装の品質をどう確認するか？
変更箇所に合うテスト、型確認、ビルド、実ブラウザ確認を行い、公開後も同じ条件で読み戻します。
コードから本番まで、利用者の経路に沿って確認する検証層
コードが動くことと、見込み客が使えることは別です。フォームならサーバーとブラウザの両方で入力を確認し、スマートフォンで押せる大きさや横スクロールも見ます。計測なら個人情報がGA4へ入っていないこと、CRMなら同じ受付IDで重複しないことを確かめます。
エラーが出ないだけでは完了にしません。公開URL、レスポンス、CRMの保存結果など利用者が通る経路を最後まで読み戻します。失敗した場合は原因を残し、同じ確認で再検証します。
他社事例の数字をどう読むか？
他社の短縮数字は条件付きの参考値とし、自社の対象業務や合格線へそのまま置き換えません。
OpenAIが紹介するNTT DATA Groupの事例では5人の経験者が3日かけていた特定のインシデント分析をCodexが30分で完了したと公表しています。OpenAIの顧客事例に記載された特定業務の結果であり、Heygoodの開発時間や他の組織へ同じ比率を約束する数字ではありません。
この事例から参照するのは短縮率より運用条件です。利用できるデータ、接続先、sandbox mode、自動化レベル、人のレビュー位置をガイドラインで決めた点は自社の対象業務を切るときにも使えます。
OpenAI Presenceの公開情報も、特定の仕事から始め、必要な知識とシステムだけを接続し、承認と人への引き継ぎ条件を決める流れを示しています。製品提供者の説明であり、第三者検証済みの共通効果とは扱いません。
自社へ持ち込むとき何を決めるか？
止まっている一件、使える資料、禁止操作、判断者、終了条件を一枚に置くところから始めます。
最初から全社業務を一覧にしなくても構いません。月曜の朝に溜まる問い合わせ、FAXからの転記待ち、請求書の照合待ちなど実物が見える一件を持ち寄ります。
相談時にそろえるのは次の七つです。
- 誰の何の待ち時間を減らしたいか
- 一週間または一か月の件数
- 入力と完成物の実例
- 判断に使う正式な資料
- AIへ渡せないデータ
- 自動実行しない操作
- 続行、縮小、停止を決める人
候補業務の選び方はAIエージェント導入はどこから始めるか、本番へ進む基準はAIエージェントPoCの終了条件で確認できます。
Heygoodは自社運用の型をそのまま押しつけません。現場で止まっている一件を見て、AIへ任せる仕事、人が止める関門、最初の観測値を組織ごとに設計します。