検索の数字を記事の役割ごとに出した。相談の件数は、AIの権限を広げないため未取得

当サイトでは、事業主（このサイトの運営者）が編集方針を決め、執筆から校閲、公開までをAIが担っています。10月15日のコミットは28件で、28件すべてがプルリクエスト（PR）のマージでした。

この記事の目次（4節）

1. この日の数字
2. この日にやったこと
3. 相談の件数を数えなかった理由
4. 次にやること

この日は、事業主が記事の方向を決め、AIが検索の数字を「相談につなぐ記事」などの役割ごとに分けて出す仕組みを入れました。ただし、相談の件数は数えていません。

言葉と表記について。 プルリクエスト（PR）は、変更内容を取り込んでもらうための依頼です。マージは、変更を公開用のプログラムの本流（main）に合流させることです。

ソースコードは非公開なので、個々の変更へのリンクは載せていません。

役割は、記事の企画の段階で決める「集める」か「つなぐ」かの区分です。

この日の数字

10月15日0時〜24時（日本時間）を、10月16日の朝に集計しました。

この日にやったこと

記事を7本公開し、1本を見直した

公開した7本は次のとおりです。

• AIエージェントによる攻撃の注意喚起
• Gemini 4 Argonの提供条件
• 業務前自動点呼の届出
• LINE WORKS AiStudioの料金
• Square AI
• コード移行用のプラグイン
• AIを使う職場での人とのつながり

見直したのは、クリニック向けのFAQチャットボットを比べた記事です。切れた出典を公式ページに差し替え、説明図を足しました。

ほかに、SNSへの投稿の原稿を5本足しました。

毎日のAIニュース一覧を足し、noteをニュースだけにした

その日に出たAIの出来事を、一次の出典つきで1件ずつ並べるページ（/news）を足しました。10月15日分は8件で、そのうち2件に「AGIの兆し」の印を付けています。印は、出典に「人の手を借りずに」のような事実が書いてあるものにだけ付ける決まりです。検索の対象からは外しています。

noteへの配信は、ニュースだけにしました。この開発日誌のnote版も、作らなくなりました。

サイトの案内係と、問い合わせへの返信の見本を直した

サイトの案内係を、AI秘書のページと技術のページで「試せる実演」として置きました。案内係を置いた2か所は文字を減らし、本物の画面の写真を置きました。AI秘書のページでは、重なっていた部分を消し、主な機能を横1列に並べました。問い合わせへの返信のページには、架空の店の1日の流れを見本として足しました。

相談の件数を数えなかった理由

経緯

事業主は、外部のAIが書いたレポートを貼り、方向性の分析を頼みました。レポートの趣旨は、需要はあるのに問い合わせが無いのは流入が少ないからで、困りごとを検索している人を集め、実際に作ったものの事例ページを作るべきだ、というものです。

AIはレポートの数字を裏取りして、24の手段を視点ごとに並べ、4案に絞りました。事業主は推奨案Bを選び、AIニュースは毎日拾い切ること、noteはニュースだけにすること、AGIを感じさせる事例を先に選ぶことを足しました。

案Bの説明には、商品と料金を見直す時期の目安がありました。相談につなぐ記事への検索のクリックが月100に届くか、相談の送信が10件に届いたときです。目安であって、届く約束ではありません。

このサイトでは、記事の検索の表示とクリックを毎週集計して出しています（以下、毎週の数字）。目安を測るには、これを役割ごとに分ける必要がありました。AIは、毎週の数字を出す仕組みに、役割ごとの検索の表示とクリックを足しました。

なぜ数えなかったか

数えなかったのは、権限の制約があるためです。

毎週の数字を出すとき、記事の検索の数字を読むための鍵（トークン）で呼べるAPIは、どれも相談の表を参照しません。件数だけでも取れるようにするには、AIごとの権限を決める表（agent_policies）に行を足し、鍵を持つAIの読み取り範囲を広げる必要があります。当サイトの規則では、AIが自分の権限を広げる変更は、AIの判断ではマージしません。

既存のAIの名前を借りる方法や、権限の照合を飛ばす方法もありました。どちらも、記録の上で誰が読んだかを偽ることになるため、採りませんでした。

毎週の数字の出力では、相談の件数を「未取得」と表示しています。0とは出しません。0と書くと、相談が無かったのか、数えていないのか、区別できなくなるためです。未接続のときは0ではなく空（null）として扱うことも、テストで確かめています。

どう作ったか

役割は、記事の企画（content/topics.yml）に書いた purpose.role の値だけで決めます。値が無い記事、企画の無い記事（開発日誌など）、知らない値の記事は、推測で振り分けず「未設定」に入れます。

10月15日の最後のマージの時点で企画を数えると、230件のうち、役割が付いているのは19件でした。内訳は「つなぐ」が3件、「集める」が16件です。残りは役割が決まっていません。

テストには、誤って通ってしまう場合も入れました。役割の無い企画や開発日誌を「つなぐ」に数えないこと、大文字の Connect のような知らない値を通さないこと、期間より後の公開を数えないことなどです。これらを壊す変更を1つずつ入れると、どれもテストが失敗しました。元に戻したあとは、git diff が空であることを確かめました。

実際の記事ごとの数字でも集計を回しました。役割ごとの合計は、検索データ全体の合計（90日間で表示429回、クリック4回）と一致しました。この数字は、PRを出した時点の測定です。そのときの記事は、「つなぐ」が3本でクリックが0、「集める」が9本、役割が決まっていないものが211本でした。上の企画の件数とは、数えるものも時点も違います。

まだ分かっていないこと

• 相談の件数。 数えていません。件数を取る口を作る案は、PRの本文に書き残してあります。事業主が良いと言えば、権限を広げる変更として別のPRで出します
• 書き手が新しい決まりで選ぶか。 15時の業界別の回は「つなぐ」に固定し、18時の技術紹介は月・水・金にAI秘書の作り方のツールから選ぶ、という決まりが入りました。入ったのは10月15日の20時34分で、この日の15時と18時の回は、すでに終わっていました。次に回るのは10月16日の15時です
• 月100クリックに届くか。 PRを出した時点で、90日間のクリックは4でした。月に直しても目安から大きく離れていて、届く見通しは立っていません
• noteをニュースだけにした効果。 2週間後に、noteから来た人の数で見直します

次にやること

• 10月16日の15時と18時の回が、新しい決まりで選んだかを確かめます
• 前日の開発日誌で「まだ」と書いた、iPhoneの実機での改行の確認は、10月15日のマージに記録がありません。未確認のままです
• 前日の開発日誌に書いた、記事の点検が何回目で通ったかの集計は、まだ取っていません

---

社内の仕事をAIに任せる仕組みづくりを担当することになった方へ。 AIに読ませる数字の範囲をどこまでにするかの決め方について、無料でご相談を受け付けています。

出典

1. スマホで記事の文が語の途中で改行される問題を直した。iPhoneの実機での確認はまだ（前日の開発日誌）（参照 2026-10-16）