朝8時。AIエージェントが問い合わせの正本となるCRMを開きます。検索流入だけ増え、適格問い合わせが増えていなければ、記事を足す前に導線や相談メニューを確認。いちばん詰まっている場所を一つ選び、次の4時間で手を入れます。
昼12時にコードを直し、テストと実ブラウザで確認します。夕方16時に公開結果を読み戻し、夜20時に続ける施策と止める施策を選び直す。Heygoodが自社で回している一日の流れです。
AIエージェントに任せている仕事は?
調査から記録までをAIエージェントが担当し、公開や契約など影響の大きい判断を人に戻します。
「競合調査」「記事作成」という作業名だけでは渡しません。増やしたい成果、正本となる数値、変更できる範囲を先に決めます。AIエージェントの担当は証拠を集め、変更し、結果を確かめるところまでです。
問い合わせ、資料取得、商談履歴はbiz platform CRMで確認します。GA4のイベント数をそのまま成果に数えず、CRMで適格と判定された問い合わせだけをNorth Starへ加算。画面上の反応と営業成果を分けています。
| AIエージェントへ任せる仕事 | 人が判断する仕事 |
|---|---|
| 現在値と前回差分の確認 | North Starの変更 |
| 最大の詰まりを一つ選ぶ | 広告費、契約、料金の決定 |
| 記事、導線、計測、コードの変更 | 個人情報を含む外部送信 |
| テスト、ビルド、実ブラウザ確認 | 法務表現と実績表現の承認 |
| 証拠と次の観測値の記録 | 破壊的変更とDBスキーマ変更 |
任せる範囲の考え方はAIエージェントにどこまで権限を渡してよいかで詳しく整理しています。
4時間でどこまで進める?
一回の枠で一つの詰まりに絞り、変更を一件終え、確認の証拠と次に見る数字まで残します。
記事、CTA、フォーム、CRMを同時に変えると、数字が動いた理由を追えません。検索表示が少ないなら記事、フォーム開始後に離脱するなら入力画面、保存に失敗するならCRM連携だけ。触る場所を一つに絞ります。
| 段階 | 4時間枠で残すもの | 終了時の確認 |
|---|---|---|
| 観測 | 前回からの差分 | 古い数値を使っていないか |
| 選択 | いちばん大きな詰まり | ほかの場所を同時に触っていないか |
| 実行 | 公開できる変更一件 | 問い合わせにつながる変更か |
| 検証 | テスト、画面、計測の証拠 | 決めた成功条件を満たしたか |
| 記録 | 次回観測値と中止条件 | 次の担当が判断をたどれるか |
調べて終わりにはしません。記事構成、設定案、検証手順など承認後すぐ動かせる形まで仕上げます。状況報告だけを残す運用では次の4時間も同じ場所から始まるためです。
人に戻す判断は?
公開、個人情報、契約、料金、法務表現、破壊的変更を作業前から人の承認対象にしています。
承認は最後に足す安全装置ではありません。AIエージェントが止まる場所として、仕事を始める前に決めます。通常の記事修正やテストは進めても、未レビュー記事の検索公開、顧客への一斉送信、DBスキーマ変更の前で停止。担当者へ判断を戻します。
AISIの評価観点ガイド第1.20版はAIエージェントの自律的な挙動と外部環境との相互作用について、観測と制御を評価項目に挙げています。Heygoodでも文章の正しさだけで済ませません。何を変え、どこで止まり、誰が承認したかを追います。
次の施策はどう決める?
検索表示からCRMの適格判定までを並べ、最初に数字が落ちた場所から次の一手を選びます。
問い合わせが0件でも、すぐ記事を増やすとは限りません。検索結果に出ていないのか。記事を読んでもCTAを押さないのか。フォームを開いても送らないのか。CRMへの保存で止まっているのか。落ちた場所ごとに手を変えます。
| 観測する場所 | 分かること | 次に選ぶ施策の例 |
|---|---|---|
| GSC | 検索表示、クリック、検索語 | 記事制作、タイトル修正 |
| GA4 | 記事閲覧、CTA、フォーム | 導線、相談メニューの変更 |
| Clarity | スクロール、迷い、誤操作 | 画面構成、入力負担の変更 |
| biz platform CRM | 適格判定、商談化、流入元 | 読者設定、施策配分の変更 |
| Git・公開URL | 変更内容、公開結果 | 継続、修正、停止の判断 |
クリック数と営業成果を同じ箱へ入れないことが前提です。資料取得も問い合わせと分けます。資料を読んだ人が後日相談した場合だけ、同じCRM上で関係を確認します。
実装後に何を確かめる?
コード、画面、計測、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に任せる仕事、人が止める場所、最初に測る数字を組織ごとに決めます。




