AIで制作量を増やせても、読者に届くとは限りません。この記事では、PLaiの2026年7〜8月の検索記録と制作上の不具合を振り返り、観測した数字、そこから言えること、まだ判断できないことを分けます。
主に扱うのは、記事の量産方針を見直した記録、内部リンク変更と検索表示の変化、画像の表示崩れや並行編集への対策です。会社の売上やAI担当数から効果を説明するのではなく、一件ごとの測定条件と確認方法を示します。
検索データは当時の保存データ、制作上の出来事は当時の運用記録を参照しています。2026年10月の再点検では、集計期間と記事の母数が異なる比較を修正しました。現在の運用実績を示す記事ではありません。
実務で試すときに確認したいこと
運用実績を自社の計画に使うときは、対象期間・件数・人が行った作業を同じ表に置きます。自動実行された件数が多くても、その後の確認や修正が増えていれば負担は減っていない場合があります。公開された数字の測定範囲を保ち、自社では別の条件で検証が必要な点を残してください。
この記事の「運用レポートで分けて見る数字」を、自社の業務[業務名]に置き換えて検討します。
前提:[現在の手順・使ってよい資料・確認担当]
確認したいこと:実行件数と、確認・修正を含めた業務負担を分けて読めていますか?
上の資料で分かること、不明なこと、最初に確認することを分けて整理してください。事実や実績を作らず、提案には理由を添えてください。外部送信や設定変更は行わず、検討用の案を出してください。結論:制作の自動化と、成果の検証を分ける
AIは記事やWebページの制作、資料の整理を進められますが、作成量だけでは品質や事業成果を判断できません。担当者は根拠と成果物を確認し、公開・外部送信・金銭に関わる操作は承認の範囲を定めます。本記事の検索記録から確認できるのは、特定期間の表示・クリックと、その前後に行った変更です。変更が増減の原因だったかは、別に検討する必要があります。
この記事の数字はどう取ったか(測定条件)
検索データは当時のGoogle Search Console保存データを使います。社内記録上、このプロパティで実データを確認できるのは2026年7月15日以降です。7月1日を開始日に指定した古い集計も、7月1〜14日が測定済みのゼロだったことを意味しません。日付、対象ページ、集計方法が違う数字を直接の前後比較にしないよう注意します。APIでは確定済みデータを取得できますが、「3日前なら必ず確定」という判定はせず、取得条件を記録します。Search Analytics APIの公式仕様も参照してください。
担当業務と、人が確認すること
以下は、当時の制作・運用記録を役割別に整理したものです。AIの役割定義があること、実行したこと、結果を確認したことは別に扱います。表の担当区分を、人間の雇用人数や稼働時間へ換算することはできません。
| 部署 | AI社員の役割の例 | 任せている業務 | 人間がやること |
|---|---|---|---|
| マーケティング | 記事・配信文・検索分析 | 構成や本文の作成、検索データの整理 | 出典、実績表現、公開・配信内容の確認 |
| 制作 | Web制作担当・スライド担当・動画編集担当・図解担当 | HP/LPの実装、登壇資料、教材動画の編集、画像生成 | 要件の指示と検収 |
| セールス | 商談フォロー担当・顧客対応担当 | 提案書と見積書の下書き、返信文の作成、商談議事録の要約 | 商談そのもの・送信の承認 |
| バックオフィス | 帳票・集計・定期処理 | 書類の下書き、集計、実行状態の整理 | 金額・宛先・対象期間の照合と操作の承認 |
役割の数と、稼働実績を区別する
AIの担当を数える場合は、役割ファイルの数なのか、期間内に実行した役割の数なのかを明記する必要があります。人数の表現だけでは、何件を処理し、どこに人の作業が残ったかは分かりません。運用の記録には、依頼内容、成果物、確認結果、手直しと所要時間を残します。
一件の仕事で、依頼・制作・確認・実行を記録する
たとえば記事なら、対象と読者の課題を決め、参照資料から構成と本文を作り、校閲と表示確認を行います。公開の承認を得て反映した後は、実際のページが確認済みの内容と一致するかを照合します。AIの作業報告だけで公開完了としないことが、工程を評価する前提です。
この流れを見直す際は、担当者が補足した前提や修正理由を記録します。資料へ残しただけでは次回に使われる保証はないため、次の仕事で参照されたかも確かめます。
記録①:量産から、取材・改善を含む一枠へ見直した
最初の記録は、記事数を増やす方針を見直したときの集計です。数字を、そのまま一般的なSEO効果の証明として扱うことはできません。
当時の運用記録には、2026年7月9日に毎日5〜7本の制作を始め、3週間で58本を公開したとあります。7月30日の方針変更に使った集計では、公開から14日以上たった記事40本を対象に、次の値が記録されています。抽出期間の指定は7月1〜28日ですが、実データのある期間は7月15日以降という制約があります。
| 指標 | 実測値 |
|---|---|
| 公開から14日以上たった記事(熟成記事) | 40本 |
| その40本の検索クリック合計 | 78クリック |
| うちクリックゼロの記事 | 27本(68%) |
| 当時の記録で検索表示が0だった記事 | 10本。表示0だけで未インデックスとは判断できない |
| 別母数の集計 | 上位6本の80/96クリックという記録もあるが、40本の78クリックとは対象が異なるため比較しない |
カテゴリ別に見ると、勝ち筋は最初から偏っていた
当時のカテゴリ集計では、Obsidian関連にクリックが集まっていました。これを受け、7月30日に毎朝の枠を新規記事か既存記事の改善のどちらか一つへ変更しています。ただし、テーマの需要、公開期間、検索順位、記事の質などが同時に違うため、この分布だけから「一次情報だから読まれた」「本数を減らせば伸びる」とは判断できません。自社の方針変更の記録として扱います。
当時の方針と数字の出典は、PLaiの2026年7月30日の記事運用記録です。外部製品の公式説明を、自社の検索実績の根拠として扱っていません。
方針変更をまたぐ32日間の集計
2026年7月15日〜8月15日の保存済み日別データを、記事ページごとに再集計すると377クリックでした。ブログ一覧ページの2クリックは含めません。上位5記事は318クリックで、全体の約84%です。当時の分析記録には61記事中28記事がクリック0とありますが、先の40記事とは対象も期間も違います。さらに、この32日間は7月30日の変更前を含むため、「転換後の改善率」として比較することはできません。
記録②:内部リンク変更と、後日の検索表示低下
当時の変更記録では、7月30日にObsidian入門記事への内部リンクが59本から7本へ変わっています。その後に検索表示が低下しましたが、時間的に前後しているだけで原因が確定したことにはなりません。
保存済み日別データでは、8月2日〜4日の表示は54・58・44回、8月5日は10回でした。7日単位では8月2〜8日が175表示、8月9〜15日が13表示です。当時のURL検査記録では最終クロール日は7月20日でした。これは7月30日の変更より前なので、リンク変更がクロール停止を引き起こしたと、この情報だけで説明することはできません。
この事例から残すべき手順は、リンク変更の前後で対象ページ、リンク元、クロール情報、検索データを保存することです。リンク数の一律の下限や、減らせば必ず露出が落ちるというルールは導けません。復元や再クロールを依頼した場合も、取得や回復を保証するものではないため、後日の状態を確認します。Googleの再クロールに関する説明も参照してください。
記録③:変更台帳と検索データを突き合わせる
変更日や対象が残っていないと、数字が動いた後で調べる範囲が広がります。時系列を記録する目的は、原因を自動で確定することではなく、検証する候補と未確認事項を残すことです。
当時は、変更台帳、日別検索データ、変更前後7日間を比較する処理を整備しました。台帳には変更日、対象URL、変更内容、公開確認を記録します。検索データは同じ取得条件で保存し、前後の増減を調べます。曜日、季節、検索需要、他の変更も影響するため、7日間の比較結果には因果関係の結論を付けません。
タイトル変更の評価でも、変更内容が検索エンジンに取得されたかは確認項目の一つです。ただし、クロール日だけからタイトルの採用や順位変化の理由までは分かりません。公開日、取得状況、対象クエリ、同期間の他の変更を並べ、「観測できたこと」と「原因の候補」を分けて記録します。
失敗3つと、その後に入れた機械ガード
以下は当時の不具合記録と、確認すべき対策を整理したものです。一つの検査を追加しただけで、同じ種類の不具合をすべて防げるとは扱いません。
| 失敗 | 起きたこと | 入れた機械ガード |
|---|---|---|
| 画像の寸法変更による表示崩れ | 寸法属性とCSSの組み合わせで画像が縦長になった | 資産の存在検査に加え、実際の表示寸法・縦横比をPCとスマートフォン幅で確認する |
| 内部リンク変更後の露出低下 | リンク変更の後に検索表示が低下したが、原因は確定していない | 変更台帳、リンク元、クロール、検索データを残し、他の要因も調べる |
| 並行編集による上書き | 同じファイルの別々の変更が、後の保存で失われた | 差分だけでなく、編集前の版と保存時の版を照合する。競合時は止め、復元できる履歴を残す |
不具合の原因に合う検査を選びます。画像ファイルの存在確認では縦横比の崩れは検出できず、差分編集だけでは同じ箇所の競合を防げません。対策後は、元の失敗条件を再現して止められるかを確認します。
できていないこと: AIに任せていない仕事と、この体制の限界
金銭、外部送信、公開などは、内容と対象を確認し、承認した範囲で実行します。人が承認することと、人が必ず実行ボタンを押すことは同じではありません。誰が何を承認し、誰が実行し、どの結果を確認したかを分けて記録します。経営上の判断や関係者との合意形成も、AIの作業結果だけで完了扱いにはしません。
仕組みの導入後も、知識の更新、品質確認、例外対応、接続先の変更への対処が残ります。二つ目以降の業務で再利用できる部分があっても、業務ごとの権限と合格条件は確認し直してください。
自社で始める場合の3つの進め方
最後に、このレポートを読んで「自社でもやるか」を考える方向けに、現実的な3つのルートを整理します。
自作する場合は、まず一業務の入力と完成見本を揃え、外部操作を含まない下書きで試します。ツールの利用料だけでなく、設計・検証・保守に使う時間も記録してください。AI社員の作り方で、対象業務の整理から確認できます。
学びながら進める場合は、実際に扱いたい業務と、使える資料を整理します。AGI CAMPを検討する際も、対象業務、受講条件、個別支援の範囲を確認してください。
外部へ依頼する場合は、設計、実装、現場への説明、改善方法の引き継ぎのどこを任せるかを決めます。PLaiのAI社員構築代行では、対象業務と社内体制に合わせて支援範囲を相談できます。期間・回数・費用は案件の条件を確認してください。
よくある質問
Q. 役割を持つAIは、どのような環境で使えますか?
A. 必要な資料を参照し、対象の作業を実行できる環境を選びます。ローカルのMarkdownを使う構成の一例はObsidianとClaude Codeの連携ガイドで説明しています。保存形式だけでなく、利用する情報と操作の権限も確認してください。
Q. 検索の数字から、何が判断できますか?
A. 記載した期間と対象について、保存データにある表示・クリックを確認できます。公開時期の異なる記事や別の集計期間を直接比べて、改善率や施策の効果を断定することはできません。本記事ではその違いを明記しています。
Q. 記事を毎日7本から1本に減らして、検索流入は落ちませんでしたか?
A. 本記事の32日間は方針変更前の期間も含むため、転換後だけの効果は判断できません。記事の母数も40本と61本で異なります。効果を比較するには、同じ対象記事と集計条件を揃え、同時期の他の変更も調べる必要があります。
Q. 一人会社でなくても、この体制は再現できますか?
A. 役割、資料、確認工程を整理する考え方は取り入れられます。ただし、複数人の場合は合意と権限、代理担当の設計が加わります。人数が増えれば効果も大きくなるとは限らないので、一業務で確認してください。
Q. 一業務を運用へ移すまで、どれくらいかかりますか?
A. 資料の状態、接続先、例外の数、確認できる担当者によって変わります。初稿が作れるまでと、例外を含めて運用できるまでを分け、試作と検証の予定を立ててください。
まとめ: 数字は嘘をつかないが、読み方を間違える
今回の記録で確認できたのは、記事制作の方針変更、特定期間の検索データ、制作上の不具合です。検索の増減を施策の因果と同一視せず、母数と期間を揃えて読みます。失敗への対策も、その原因を検出できるかまで確認することが大切です。
本記事は2026年7〜8月の記録を、2026年10月に集計条件と説明の範囲から見直したものです。自社で試す際は、一件の入力、成果物、人の確認時間、未完了事項を残し、その条件で結果を評価してください。
AI活用の「何から?」を、
30分で解決。
御社の仕事を伺い、AIに任せる業務と
最初に試すことを、一緒に決めます。
- AIに任せたい仕事を整理
- 自社に合う始め方を具体化
- 明日からの一歩を決める

次は、御社の話を聞かせてください。
参考資料・出典
製品の機能・仕様や外部の発表は、以下の資料を参照しています。PLaiの運用例・実績と、公式の説明を分けてご覧ください。
- Claude Code公式ドキュメント:概要
Claude Codeの機能と利用できる環境
確認日: - Obsidian公式ヘルプ:データの保存方法
VaultとローカルMarkdownファイルの保存方式
確認日:







