1. AIに任せた作業と、人が決めたこと

このサイトでは、会社説明の統一、記事・事例・ガイドの整備、関連リンクや共通部品の修正などを進めています。自社HPで始めたGEO/AEO対策では、何を変え、何がまだ確認できていないかをまとめました。その変更を進める側の記録が、この記事です。

AIに任せるのは、合意した範囲での調査、文章・コードの変更案、ビルドや画面の確認、レビュー指摘への修正です。作業と確認の役割を分け、変更内容と確認結果を記録します。

人は「何を優先するか」「どの範囲まで任せるか」「実績として公開できる根拠があるか」を決めます。着手の承認と本番公開の承認も分けています。変更案ができたことや確認が通ったことだけで、公開を承認したとは扱いません。

自社サイトでは、承認された変更を本番用のブランチへ取り込むと、公開処理が始まります。そのため、取り込みの承認は本番公開の承認でもあります。この記事も、本人が内容を確認して公開を承認する対象です。

2. 期間内の件数と、数え方

対象は自社サイトの開発管理履歴です。2026年9月29日0時〜10月8日12時44分58秒（日本時間）を集計期間とし、2026年10月8日にGitHubの読み取り用CLIで取得しました。期間外の記録は除外しています。

Issueは作業・調査の課題、PRは変更案を確認して取り込む単位です。1つの課題を複数の変更案に分ける場合や、記録だけの課題もあるため、両者の件数は一致しません。

項目 このサイトでの記録 数え方
作成したIssue 117件 期間内に作成された課題。PRは除外
マージしたPR 144件 期間内に取り込まれた変更案。作成日が期間前のものも含む
Issue作成から最初の関連PRマージまで 76件の中央値：約1時間36分 期間内に作成され、期間内のマージ済みPRに終了対象として関連付けられた課題を集計
レビューの正式な差し戻し 0回 上記144件のPRに記録された、期間内の「変更を要求する」レビューの回数
着手承認ラベルの付与 99回 Issueへの着手承認を示すラベルの付与イベント
公開承認ラベルの付与 36回 PRへの本番公開承認を示すラベルの付与イベント
本番公開処理の成功 144回 期間内に開始し、取得時点までに成功完了した公開ワークフローの実行数

作成からマージまでの時間は、作業時間ではない

時間の集計では、PRに明示された終了対象のIssueとの対応を使い、同じIssueに複数のPRがある場合は最初のマージを採用しました。対象76件の最短は約2分41秒、最長は約45時間52分です。関連付けを確認できない課題や、未完了の課題は含めていません。

この時間には待機や人の確認も含まれます。また、最初のPRが取り込まれても、後続の修正が残る場合があります。実際の作業時間、課題全体の完了時間、従来との速度比較には使えません。

差し戻し・承認・公開の件数にも限界がある

正式な差し戻し0回は、修正指摘がなかったという意味ではありません。コメントや対話で伝えた修正、AI同士の確認は、このレビュー件数では把握できません。それらを含めた差し戻し総数は未集計です。

承認は現在残っているラベルではなく、付与した履歴を数えました。外して付け直した場合も1回ずつ含めるため、承認した課題数・人数ではありません。付与したアカウントの記録だけでは、本人の操作と、本人の合意に基づく代理操作を区別できません。99回・36回を「人が直接操作した回数」とは断定しません。

本番公開は、公開処理の成功を単位にしています。記事の公開本数や、見た目が変わった回数ではありません。運用資料だけの変更でも公開処理は起動します。この集計では全144回の配信先への転送内容や公開画面を個別照合しておらず、すべて異なる内容が配信されたという意味でもありません。

3. 進められたことと、止まったこと

変更と承認の履歴を残せた

期間内に144件の変更案を取り込んだことは確認できました。会社説明、ガイド、事例形式、内部リンクの具体的な変更は、GEO/AEOの実践記事で紹介しています。

今回、履歴から変更・承認・公開処理を別々に数えられたことは、次の運営判断に使える材料です。一方、件数が多いことだけで、品質が高い、費用が下がった、検索や相談の成果が出たとは判断できません。

ファイルの扱いを変えたら、自動作業が止まった

2026年10月8日、運用手順のファイルを別のファイルへの参照リンクにした変更により、自動作業の安全確認が止まる不具合がありました。調査の課題は、作業を始めた直後に停止しました。

原因は、参照リンクを含むファイルの扱いと、安全確認の条件が合っていなかったことです。安全確認を外して通すのではなく、参照リンクを通常のファイルへ置き換えました。同じ手順を複数箇所で使う場合は、同じ変更で内容を揃えるルールも運用資料に残しています。この修正は、同日11時16分15秒（日本時間）に取り込まれました。

ここで確認できたのは、原因に対応した変更が取り込まれたことです。止まった調査がその後最後まで完了したかは、今回の集計では確認していません。修正を取り込んだことと、運用の復旧を確認したことは分けて記録する必要があります。

この経験から、ページの表示を変えない運用ファイルの変更でも、自動作業を止めることがあると分かりました。ファイルを変更するときは、そのファイルを読む側の制約も確認対象にします。

4. 10月8日から、部門で分担する体制へ

2026年10月8日、サイト運営を5つの部門で分担する体制に切り替えました。

  • 司令部：優先順位と着手・公開の判断を整理する
  • マーケティング部：サイト分析、情報収集、計測、発信を担当する
  • コンテンツ制作部：記事・事例・業務別ページを作成・補強する
  • デザイン・開発部：共通部品、見た目、サイトの基盤を整える
  • 品質管理部：定期点検と改善提案を行う

各部門が見つけた改善は候補として残し、優先順位を人と相談してから着手します。着手の承認は、人が合意した範囲で代理の付与も認めます。本番公開の承認は本人が行うのが原則で、例外は個別に合意した範囲に限ります。今回の記事は自動マージの対象にしません。

部門分担は集計期間の最終日に始めたため、今回の件数をこの体制の成果とは扱いません。次回以降、担当が明確になったか、候補から着手までの判断が進んだかを、記録から確認します。

5. 次回に残すことと、自社で試すときの確認点

月1回の連載として、次回も対象期間と数え方を付け、進んだことと止まったことを残す予定です。今回取得できなかった、対話を含む差し戻しの回数や、不具合修正後の運用結果も確認対象です。集計方法を変える場合は、今回の数字とそのまま比較できるかを明記します。

自社でAIにサイトの作業を任せるなら、まずは1つの変更について、次の点を決められます。

  1. 目的、変更する範囲、完了とする条件を記録する。
  2. AIが作業する範囲と、人が判断・確認する範囲を分ける。
  3. 文章・表示・リンクの確認結果を、変更案と一緒に残す。
  4. 公開の承認を得てから反映し、公開後の状態も確認する。
  5. 止まった場合は、原因・修正・復旧確認を分けて記録する。

hirostaが提供している開発・改善の進め方は、AIを使ったシステム開発・改善をご覧ください。この記録は自社サイトでの実践であり、お客様の案件でも同じ件数や所要時間になることを保証するものではありません。