MORNING
2026.09.11   FRI
9/11 朝の実行記録 / 名前を匿名化
夜間に進めた仕事

朝、ここから
始められるように。

今日の打ち合わせ準備に加え、LPの計測改善を実装し、明日の撮影台本を読みやすい画面にしました。朝の判断と、すぐ使える成果をここから開けます。

実際の朝の準備を公開用に匿名化しています。社名・人名・内部リンクを伏せ、作業内容・数値・確認結果を残しています。記載の進捗は9月11日朝時点の記録です。

まず開く、3つ。

前回の経緯と正本を確認して準備しました。

01 / MEETING
13:00–15:00

企業A
打ち合わせ準備

前回のビジョン策定ヒアリングから、自社らしさを日々の判断に使う言葉へ。話し始めの案と、今日の4つの問い。

作成済み
02 / KICKOFF
19:30–20:00

企業B
方針相談の準備

先方の情報管理への懸念、現在の契約書案、チームの役割。9/16のキックオフに向け、30分で揃える5点。

作成済み

今日の予定

Google Calendarの有効な予定

12:00–13:00

ランチ余白

カレンダーに登録されています。

13:00–15:00

企業A打ち合わせ

ビジョン策定の前回メモをもとに準備済み。

18:30–19:30

Astra × Image 2.5 勉強会

本編50分＋質問10分。19:30から次の会議が続きます。

19:30–20:00

企業B キックオフ方針相談

Google Meetを開く
20:00–20:30

企業Bのラップアップ

会議後の整理枠として登録されています。

取消を確認した予定17:00 開発支援 MTG / 18:00 経営会議 / 18:00 企業Bの事前ブリーフィング。Notionの残存2件は書き換えていません。経営会議は明日9/12 13:00–15:00の予定が有効です。

9/11 7:22 JSTにカレンダーを再確認。夜間の確認後、上の有効な予定に変更はありませんでした。

来週、先に確認しておくこと9/15（火）15:30のマーケ戦略MTGは、Notionの担当にあなたが入る一方、カレンダーの招待先には見当たりません。参加する場合は15:00–16:00の価値観MTGと重なるため、参加予定を確認。

9/16（水）は9:30–11:00の撮影から、11:00の企業B・キックオフへ続きます。資料と接続準備は前日までに済ませると安心です。

あなたが決めること

判断が必要な部分に絞りました。

企業A

自社らしさを、仕事中のどの判断で使うか。

「自分たちで検証する」「相手の選択肢を広げる」という前回の考えを、日常の具体例で先方と揃えます。

企業B

最初の業務、情報の扱い、判断者を揃える。

契約書案には3年Roadmap・全社AI活用基盤準備も含まれます。9月に用意する範囲と、PM・技術・事業判断の役割を確認します。

明日の撮影

撮る原稿と、LPの「3分」表記を揃える。

原文は2,102字。尺を優先する場合の850字案も用意しました。採用前に一度読み、実際の長さを確かめられます。

勉強会

終了時刻と、共有する画面を決めておく。

19:30に次の会議が始まります。登壇ノートはスライド内で開くと参加者にも見えるため、別画面のノートを使うと進めやすくなります。

夜間に進んだこと

朝の確認済み / 最終更新 07:25 JST

打ち合わせ準備

今日の2件の準備メモを作成

前回議事メモ、顧客の要望、契約書案を読み、話すことと判断事項まで整理しました。

作成済み
予定の照合

Notionに残る中止済みの会議2件を特定

Google Calendarのcancelled記録と日時を確認。今日の有効な予定と分けて表示しています。

確認済み
LP計測

視聴進捗と予約クリックを追う実装を作成

開始・25/50/75%・予約ボタン表示・クリックを計測。既存の視聴条件と予約URLを守り、別ブランチに保存しました。

公開前
明日の撮影

新台本を、そのまま読める画面に

カレンダーでも9/12 10:00–11:00を確認。8章の移動と自動スクロール。原文2,102字は、毎分300〜400字の仮定で約5〜7分です。LPの「3分」表記との判断点も添えました。

撮影用台本を開く ↗
作成済み
日曜のラジオ

3つの題名から、収録前の原稿案を作成

フィードバックの回数・批判の質・見る基準を変える話。仮の具体例と、聞いた人が試せる指示文を添えています。

収録前の下書き
広告の運用準備

18.2万円の実績と、成果11件の中身を確認

AD事業の直近30日を点検。売上と混同しやすい計測値を切り分け、実績を再点検するSkillを作成しました。自動取得の認証と、研修事業のMetaアカウント特定が残ります。

点検・仕組み作成済み
社内AIのCron

朝も開始は届く一方、一覧と終了の取り込みが不足

7:24の再確認では、直近24時間の受付・開始が各61件。最新の開始は7:20です。一覧の元データは9/7のままで、新画面のCron終了は未受信。実行端末で取り直す範囲を特定しました。

実行端末の確認待ち
PJ/TASKダッシュボードGoogle Calendar勉強会の配布ガイド ↗

各メモの提案・話し始めの案は、会議で使うための下書きです。契約書は現在の「案」を確認したもので、締結済み条件ではありません。外部送信・共有・本番変更・課金は行っていません。

13:00–15:00 / 前回の経緯と今日の論点

企業A打ち合わせ準備

2026年9月11日 13:00〜15:00 ／ あなた用

前回の話を踏まえると、今日は「自社らしさを、日々の判断に使える言葉へ落とす」ところから入れます。 9月9日の議事メモと既存の予定を確認しました。今日の正式なアジェンダは予定欄にないため、以下は前回の続きを話すための準備メモです。

最初の1分で共有すること

前回の話で大事にしたいのは、良い言葉を作ることだけでなく、普段の仕事で判断に使える状態にすることです。自分たちで試し、良いと思えたものを届ける。メンバーにも、お客様にも、考え方が変わることで選べることが増える体験をしてほしい。その考えを、日常で自然に使える言葉にしたいです。

上記は前回の発言をもとに整えた話し始めの案です。最終的なミッション・ビジョンの決定文ではありません。

前回から引き継ぐこと

論点9月9日の議事メモで確認できたこと今日のつなぎ方
自社らしさ研究者に近い。自社で検証し、独自の知見にしてから提供する「何をやるか」と同時に「どういう状態なら提供するか」まで言葉にする
変えたい組織の状態団結力、共通言語、やり切る姿勢を強めたい行動指針を、会議・顧客対応・制作で使う問いに変える
提供したい価値思考の変化を通じて、相手の可能性や選択肢を広げるお客様が変化を感じる場面を1つずつ挙げる
日常で使う言葉「そもそもゴールは何か」「アウトプットは何か」「原則」既に使っている言葉を起点にする
ビジョンの言葉「この世界をめっちゃ良くする」が浮かぶ。「英語のビジョン案」は日常では使われていない言葉の格好よさより、メンバーが自然に口にするかで比べる
「余白」の意味単に好きに過ごすことと受け取られる懸念がある新しい選択肢を選ぶための時間・能力・資源、という意味を具体例で確認する

今日話しやすい4つの問い

  1. お客様の何が変われば、自社が関わって良かったと言えるか。 作業時間、判断の速さ、自分で試せる範囲など、実際の変化で説明する。
  2. 売上につながりそうでも、自社が引き受けないのはどんな仕事か。 検証していないことをできると約束するなど、提供方針の境界を明確にする。
  3. バリューを守れている場面を、メンバーが見分けられるか。 「目的を確認した」「完成物を実際に動かした」「次に必要な判断を示した」といった行動で確認する。
  4. 明日から会議で使うなら、どの言葉が自然か。 新しい抽象語を増やす前に、既に使っている問いとつながるか試す。

言葉を比べるための具体例

これは行動指針の完成案ではなく、先方と議論するときの材料です。

場面判断の問い行動にすると
新しいAI機能を見つけた自分たちで使って、何が良くなったか実物、失敗した条件、再現できた条件を添えて紹介する
顧客から制作を頼まれたどんな状態になれば仕事が終わるか目的、利用者、確認する実画面を最初に揃える
自分だけが知っている作業がある次の人が自分で進められるか手順だけでなく、判断の理由と例を残す
忙しくて改善できないできた時間を何に使いたいか空いた時間の使い道まで決めて、改善の価値を測る

組織サーベイと日程の確認

会議の最後に残すこと

根拠

確認日：2026年9月11日。送信・共有・予定変更は行っていません。
19:30–20:00 / キックオフへ向けた方針

企業B キックオフ方針相談の準備

2026年9月11日 19:30〜20:00 ／ あなた用

今日の30分では、9月16日のキックオフで「何から始めるか」「顧客情報をどう扱うか」「誰が決めるか」を揃えるのがよさそうです。 先方が特に懸念しているのは、悪意のない操作ミスでクライアントに迷惑をかけること。機能の紹介に加え、実際の業務と承認手順まで説明する準備が必要です。

先に押さえる現在地

項目確認できたこと
キックオフ9/16（水）11:00〜12:00。先方責任者から希望日時の回答があり、PMが準備担当
今日の方針相談19:30〜20:00。Google CalendarとNotionが一致。18:00の事前ブリーフィングはキャンセル済み
先方の最重要懸念クライアント企業の情報の扱い、善意の操作ミス、セキュアな現場運用
現場ヒアリング現場窓口を中心に現場の懸念を聞いてほしい、という先方の要望
経営判断への説明社内決議が必要な点は、メリット・デメリットを示してほしいという要望
チームの見せ方9/4のメモでは、PMを据える体制と、誰が何をするかを説明したいという方針。あなたら全員が全MTGに参加する前提にはしない

9/16のGoogle Calendarにも11:00〜12:00のキックオフが登録されています。あなたの回答は未回答で、直前の9:30〜11:00には撮影担当とのYouTube撮影があります。参加予定を確認し、資料と接続準備は前日までに揃えるのがよさそうです。

30分の進め方

時間話すこと終わるときに残すもの
0〜5分先方の期待とセキュリティ上の懸念キックオフで最初に伝える約束と、まだ約束できないこと
5〜13分最初に扱う業務と、試すデータ最初の対象業務、現場の窓口、持ち込めるデータの範囲
13〜20分承認・アクセス・記録の持ち方誰が閲覧し、誰が下書きを確認し、誰が反映を承認するか
20〜25分自社・パートナー企業・先方の担当範囲役割表と、経営判断が必要になったときの連絡先
25〜30分9/16に見せる内容と次の準備担当者・期限・先方に用意してもらう資料

今日決めたい5点

1. 最初の1業務を何にするか。

現場の困りごとを聞いてから絞る方針を提案します。候補ごとに、処理頻度、現在の所要時間、ミス時の影響、必要なデータ、最終判断者を揃えると比較できます。対象業務は今回の情報だけで確定していません。

2. 試行開始時のデータ範囲をどうするか。

まず架空・匿名化したデータで一連の動きを確認し、実データの利用は先方の許可する範囲を明示して始める案です。クライアントごとのデータを分ける単位と、閲覧できる担当者を最初に確認します。

3. AIが出した結果を、誰がどこで確認するか。

「入力 → AIの下書き → 担当者確認 → 承認 → 実システムへの反映」の流れを、最初の業務に当てはめます。公開・送信・更新に相当する箇所、記録が残る箇所、止めるときの担当を決める案です。これらの機能が既に実装済みとは扱っていません。

4. あなたの関わる範囲をどこに置くか。

PMがPM、技術担当が技術と実装、あなたが事業上の方針・重要判断を担う形を議論用の案にします。先方の現場窓口と経営判断者も合わせて並べれば、毎回全員を呼ぶ状態を避けやすくなります。正式な役割分担は今日確認します。

5. 9月にどこまで準備し、10月の評価を何で始めるか。

9月は対象業務の選定、データ・権限の確認、現状の時間と品質の記録、初回検証の条件を揃える案です。時間削減率などの目標値は、現状の測定前に確約しません。

契約書案で見落としたくないこと

9/11にGoogle Docsの現在の本文を読みました。以下は 契約書案の記載 で、締結済み条件の確認ではありません。

キックオフで先方に聞くためのメモ

確認項目記録する内容
一番困っている業務業務名、起こる頻度、現場担当者
今のやり方最初の依頼、使う情報、判断、最後の反映先
過去のミスどの操作で、何が起き、誰が気づいたか。個人の責任追及ではなく手順改善の材料にする
情報の扱い利用可能なデータ、利用できないデータ、顧客ごとの分離、保管先
承認日常の確認者、経営判断が必要な条件、連絡方法
最初の検証比較する現状、確認する結果、継続・修正の判断日

根拠とすぐ開くリンク

確認日：2026年9月11日。先方への送信、契約・予定の変更は行っていません。
読み取り調査 / 実行端末で確認する範囲を特定

社内AIのCron確認 — 2026年9月11日

定期実行の開始は届いています。まず直すべきなのは、Cron一覧と終了結果を現在の状態で確認できるようにすることです。

1:08 JSTまでにCloudflare D1と本人ログイン後のダッシュボードを確認し、朝7:24にD1を読み直しました。Cronそのものの停止・再開・再実行は行っていません。

朝7:24の再確認

朝の読み直しでも、優先する作業は「実行端末から現在の一覧を取り直す」「同一の実行IDで開始と終了を結ぶ」の2点です。

夜間1:08の確認記録

確認対象今回確認できたこと判断
現在の定期実行直近24時間に、Cron起点の受付60件・実行開始60件。最新の発生は9/11 00:51全停止とは判断できない。少なくとも開始の記録は届いている
新画面のCron一覧定義115件、うち有効94件。元データの日時は9/7 21:30、一覧の最終受理は9/7 21:339/11の現在設定・現在のエラー件数としては使えない
終了と失敗理由上の直近24時間のCron記録は受付・開始のみ。新画面の115件には失敗理由データが0件実行開始、処理の終了、業務上の成功を区別して確認する必要がある

旧系統の詳細ログには9/11 00:57までモデル・ツール・終了のイベントが届いていました。一方、新画面のCron受付には終了が結びついていません。現在のGitHub版の旧受信APIも、旧形式の表へ保存する処理で、新v2へ自動的に終了を変換する処理はありません。同じ処理を同じIDで結べるかは、実行端末側の記録で確認が必要です。時刻が近いことだけで、別の記録を同一の実行として結びつけてはいません。

画面上も、Cron一覧には「記録更新 9月7日 21:30」、失敗項目には「失敗理由の取り込みが不足しています」と表示されます。「表示を更新」だけで実行端末の設定を取り直せるとは扱えません。

保存されていた、優先して再確認する9件

以下は9月7日のスナップショットです。今も失敗していると確定した一覧ではありません。 失敗理由は全9件とも今回の保存先では未記録でした。

処理保存された結果その結果の実行日時（JST）元のJob ID
展示会展示会リードKPI通知（毎週月曜10時）配信失敗08/24 10:04[内部ID]
AIコンサルMTG候補の事前判定（毎日15:10）実行エラー09/07 15:11[内部ID]
学習管理システム受講生CSVをDriveへアップロード（毎晩23時）実行エラー09/06 23:00[内部ID]
学習管理システム進捗70%以上のプランニングMTG打診通知（毎朝09:00 JST）実行エラー09/07 09:00[内部ID]
社内AI同期 Slack日次差分→ローカル埋め込み（深夜3:15）実行エラー09/07 03:30[内部ID]
社内AI対応能力マニフェストの日次点検（毎朝6:25）実行エラー09/07 06:25[内部ID]
社内AI運用履歴のGitHubバックアップ監視（毎朝4:10）実行エラー09/07 04:10[内部ID]
採用KPIシート自動更新（毎朝9時・Indeed CSV自動取得）実行エラー09/07 09:00[内部ID]
採用応募者DBの日次同期（毎朝8:35）実行エラー09/07 08:36[内部ID]

業務への影響から、最初は受講生データ・採用データの同期、次にバックアップ・検索用データ更新を確認すると進めやすくなります。各処理の現状を取り直した後に優先順位を確定します。

次の作業を、ここまで絞れました

  1. 実行端末で、既存の読み取り専用Exporterを使って現在のCron情報を取り直す。 対象は 社内の保存先 と、同じ端末の実行記録です。現在のGitHub版には、エラー本文を流さず分類した失敗理由を出力する処理が既にあります。新しい分類機能の作り直しは不要です。
  2. Exporterと受信側の版を揃え、一覧の同期だけを行う。 データを埋めるために、メール・Slack・顧客データを扱う業務Cronを再実行する必要はありません。取り込み後は、受理時刻、件数、失敗理由をD1と画面の両方で読み戻します。
  3. Cron 1件について、開始から終了までの同じ実行IDを確認する。 元のJob ID、session ID、開始・終了、送信結果を追い、新画面の同じ実行に終了が届くかを確認します。正常終了したことと、送信・更新先で目的を果たしたことは別に記録します。

このMacからは、実行端末のHermesファイルや常駐プロセスへ直接アクセスできる経路が確認できませんでした。修正対象となる版と実ファイルを見られていないため、推測でパッチや再起動を行っていません。

調査の根拠

Notionの稼働履歴は9/9 03:00、別の「社内AIの別画面」画面は信号待ちでした。この2つだけで社内AI全体の稼働を判断すると誤ることも確認できました。
実装・ローカル確認済み / 本番反映前

スクリーニングLP：途中離脱を追う計測を実装

現LPは閲覧数とSpirへのクリックまで確認できました。動画のどこで止まったかを追う計測を、既存リポジトリの別ブランチに追加しました。ローカルで検証済み。本番公開とGA4への到着確認は未実施です。

現時点で分かる数字

GA4「example.invalid」（プロパティ非公開）、2026/8/14〜9/10の28日間、/screening-lp/を対象に取得。9/11 01時台の読み取りで、直近日の集計は今後変わる可能性があります。

項目取得値読み方
LP表示229回 / 176ユーザー同じ人の再訪・再読を含む
Spirへのクリック31回 / 28ユーザーリンク先ドメインはすべてapp.spirinc.com
クリック回数 ÷ 表示回数13.5%31 ÷ 229。予約完了率ではない
動画の途中離脱不明対象期間・ページの取得イベントに視聴進捗なし
面談予約完了不明Spir側の予約記録との照合が必要

この数字には媒体別の費用・面談予約完了が含まれません。広告の良し悪しや増額可否は、ここからは決められません。

先に追う導線も確認

同じ期間の流入元では、GA4のyoutube / social分類が177表示・25クリックでした。全体の表示の77.3%、クリックの80.6%に当たります。youtube.com / referralは別に1表示あり、上記には合算していません。これはGA4のセッション流入元による分類で、YouTube広告の実績や費用を示す値ではありません。

端末LP表示Spirへのクリック
パソコン15323
スマートフォン707
タブレット61

ホスト名は全件example.invalidでした。端末別の内訳も229表示・31クリックに一致しています。これだけでスマートフォンの不具合や媒体の優劣は断定できません。今回追加した進捗の記録により、特にYouTube経由で、どの段階まで見られたかを次に確認できるようにします。

追加した計測

動画の「再生開始 → 25% → 50% → 75% → 予約ボタン表示 → 予約クリック」と、種類を絞った再生エラーを記録するコードです。既存のGoogleタグを使い、1ページ内の再開や連打で同じ段階を重複計上しません。

視聴進捗には実際に見た時間を使います。途中へのジャンプやバックグラウンドの時間は加算しません。現行の視聴条件と、媒体別Spirリンク・UTMの引き継ぎは維持しています。

計測対象は会社サイトの該当LPだけです。ローカルやWorker単独のプレビューからは送信しません。URLのクエリや生のエラー文をイベントへ入れず、タグが使えなくても動画と予約導線が動くようにしています。

確認できたこと

朝の判断点

この差分を本番へ反映するか。 対象はCloudflareのscreening-lpと、WordPressの対象ページにあるプレイヤー参照です。反映時は最新のページ内容・版を保存し、他の変更を保ったうえで適用します。その後、既存のmeasurement_test=1を使ってGA4 DebugViewの到着、公開ページの再生と予約導線を確認します。

GA4のキーイベント指定・広告予算変更・Spirの予約データ連携は今回の差分に含めていません。進捗の値を通常レポートで使うカスタム定義も未作成です。

保存場所と根拠

計測に用いる既存タグIDと既存のテスト用フラグは、現在のLP内のスクリプトから確認しました。本番は更新していません。
管理画面を読み取り / 広告設定は未変更

広告の自動運用へ進む前に、成果の数え方を揃える

AD事業のGoogle広告は、直近30日で約18.2万円・Google上の成果11件。費用の99.9%が「債務整理」に集中していました。 実績と計測の中身まで確認しました。既存APIの接続が使えないため、自動運用の本番開始には至っていません。

いま動いている広告の実績

対象は「広告代理店C」配下の「ADまとめ」MCC。期間は2026/8/12〜9/10、30日間です。Google広告の現在の画面から読み取りました。

アカウント費用クリックGoogleのコンバージョン
債務整理（予算運用）182,120.47円2,31210
ICL146円41
表示対象のほか7アカウント0円00
合計182,266.47円2,31611

有効・非表示・下書きの9アカウントを表示した表と、全59アカウントを含む合計の数字は一致していました。9/10単日は2,489.45円・43クリック・1コンバージョンです。管理画面の実績はリアルタイムではなく、直近分は今後変わる可能性があります。

これはGoogle広告の集計です。Metaの広告費、ASP側の成果承認、入金や売上は含みません。利益・採算・増額の可否はまだ判断できません。

「すべてのコンバージョン」を成果件数として割らない

債務整理アカウントのアクションを開くと、同じ期間に次の内訳がありました。

アクション計測カテゴリ件数今回確認できた意味
コンバージョン購入10.00申込後のthanks.phpで記録。最後は9/10 21:00
mcvページビュー260.99最終成果とは別の行動。小数は画面の計測値をそのまま記載
その他3アクションダウンロード・見込み顧客等0この期間の取得値
すべてのコンバージョン上記の合計270.99最終成果だけの数字ではない

thanksページの10件で割ると、Google計測上の1件あたり費用は約18,212円です。承認済み成果の獲得単価とはまだ言えません。また、このアクションは1件の値を1円に固定しており、Googleの「コンバージョン値」を実売上として扱えません。

「要確認」の表示についても中身を読みました。該当のthanksページは「コンバージョンを記録中」で、注意は拡張コンバージョンの設定に関するものです。基本の計測が全停止しているとは扱いません。確認のためにthanksページを直接訪問したり、申込フォームを送信したりはしていません。

配信中の確認対象も絞れました

最近のキャンペーン診断では、9/10開始のbanner032 / 034 / 008 / 013と、9/3開始のbanner032に「有効（制限付き）」の表示がありました。各2広告にポリシー制限があり、9/10開始分は入札戦略の学習中、9/3の032にはユーザーリストが小さいという表示があります。

これは不承認・配信停止と同じ意味ではありません。改善案を作る際は、各広告の制限内容と承認済み成果を確認してから、変更する箇所を決めます。管理画面の「予算を引き上げる」という提案は適用していません。

運用の仕組みで、次につなぐもの

  1. 実績の取り込み先を固定する。 AD事業はこのMCCとAD経営管理シート。研修事業の集客は別の実績・現在の経営PL「マーケ計画」で扱う。
  2. 成果の段階を揃える。 Googleのthanks到達、ASPの成果承認、売上を同じ期間・案件で照合する。ページビューを最終成果へ足さない。
  3. 対象MCCに合うAPI認証を復旧する。 以前のユーザー認証はinvalid_grant、別の既存サービスアカウントはGoogle側の認証後にNOT_ADS_USERでした。今回、権限追加や新しい認証情報の作成は行っていません。
  4. 最初は実績取得と改善案の作成を通す。 費用・成果・制限・リンク先を取得し、変更前後の差分を確認する。その後に、対象と内容が承認された変更を反映し、管理画面で読み戻す。

旧コードはAPI v18/v19を参照していました。今回の接続確認は、現在の対応版一覧で確認できるv25を使いました。Googleは9/9にAPIアクセスの管理を開発者トークンからCloudプロジェクトへ移したと案内しているため、古いトークンを入れ直すだけで復旧したとは扱えません。対応版の公式一覧 ↗・アクセス管理変更の公式説明 ↗

朝から使える、実績の点検用Skill

個人管理Skill ads-review を作成しました。広告管理画面やCSVから読み取った実績を、期間・アカウント・通貨・成果定義つきのJSONで受け取り、集計を確認してMarkdownを出力します。

今回の9アカウントを投入し、18.2万円・2,316クリック・11件が再現されました。異常な入力を含む8件のテストも通過。自動取得・定期実行・広告変更の機能は含めていません。

Skillの保存先: 社内の保存先

研修事業のMetaは、現行アカウントの特定が残る

本人のMeta広告マネージャで、個人と会社の広告アカウント一覧まで確認できました。ただし、見えている一覧だけでは現在の研修事業配信アカウントを特定できません。初期表示の古いアカウントには未公開の編集が9件あり、そのまま保持しています。

引き継ぎメモにはMetaのデータセットIDとLP候補が載っていますが、ページ内の最終更新は6/12で、現行の広告アカウントIDはありません。7/10の確認スレッドにも現在使うIDを確定できる返信はありませんでした。データセットIDを広告アカウントIDとして使ったり、古い停止済みキャンペーンから現在の広告費をゼロと判断したりはしていません。

次に必要なのは、運用担当が現在見ている研修事業の広告マネージャURL（広告アカウントIDを含む）です。対象が揃えば、今回と同じ方法で実績の読み取りと改善案の作成を進められます。

また、example.invalidのGA4プロパティでGoogle広告リンクを取得すると0件でした。GA4が読めることと、Google広告アカウントが連携済みであることは分けて扱います。

正本と今回の到達点

実績の読み取り、着手順の整理、ローカルの実績点検Skillまで完了。広告設定・予算・権限・管理表の書き換え、自動実行の登録は行っていません。CSV書き出しはブラウザで遮断されたため、上記の数字は表示された表を読み取り、内訳と合計を照合して保存しています。
9/13の3つの題名から作成 / 収録・公開前

日曜のラジオ：話し始められる原稿3本

Notionにある3つの題名から、社内向けの短い原稿にしました。本文メモは空だったため、以下はすべて今回の構成案です。あなたの実体験や発言として新しいエピソードを作らず、例は仮の場面として書いています。収録・公開前の下書きです。

おすすめの順番は、「結局フィードバックの数」→「批判的に見てもらう」→「ある経営者ならどうする？」。まず直す回数の話、その後に指摘の質、最後に見る基準を変える話へ進めます。各原稿は単独でも使えます。

1. 結局、フィードバックを受けたあとに何回直したか

AIに何回頼んだかって、あんまり仕事の出来を説明してくれないと思うんですよね。10回やり取りしていても、ずっと同じところで迷ってることはある。

僕が増やしたいのは、作って、見てもらって、直す回数です。

たとえば、営業資料を作るとします。AIに頼んで、見た目もそれっぽいものが出てきたけど、そこで止めたら、まだ自分たちが言いたいことを並べただけで、お客さんが知りたいことには答えていないかもしれない。

実際に使う人に見てもらって、「お客さんが最初に気にするのは導入後の負担だよ」と言われる。じゃあ、説明の順番を変える。その資料で話してみたら、今度は料金のところで止まった。何が含まれるのかが分からなかった、と。

これなら、直した理由が残りますよね。

逆に「もっと良くして」を何回も繰り返すと、何を良くしたかったのか分からなくなる。表紙が青から黒になって、文章がちょっと格好よくなって、で、お客さんの疑問には答えられたんだっけ、と。

AIがあると、この途中の修正を試しやすい。だからこそ、一度の出力をずっと眺めて悩むのはもったいないなと思います。

ただ、指摘されたことを全部直すのも違うんですよ。「長い」と言う人もいれば、「説明が足りない」と言う人もいる。誰が、何を決めるための資料なのかが揃っていないと、直すたびに別の方向へ進んでしまう。

最初に目的を一つ置いておく。「この資料を見た担当者が、社内で検討を進められる」。そのために必要な指摘かどうかで選ぶ。

で、直したあとに、同じ疑問が残っているかをもう一回見る。残っていなければ、そこは終わりでいいです。新しい言い回しを探すためだけに、完成を先延ばしにしなくていい。

今日、途中になってる資料があれば、一か所だけ誰かに見てもらってください。「どうですか」だと広いので、「この説明で、次に何をすればいいか分かりますか」と聞いてみる。

返ってきた答えで、一回直す。そういう回数を、仕事の中に増やしていきたいです。

一緒に渡せる指示文

この資料を見た人にしてほしいことは【目的】です。想定読者は【読者】です。目的の達成を妨げる箇所を、本文を根拠に最大3つ挙げてください。各指摘に「どこで迷うか」「なぜ迷うか」「最小限の修正案」を付けてください。修正後は、指摘した問題が残っているかを同じ基準で確認してください。

元のタスク：ラジオ📻結局fbの数

2. AIに、ありえないぐらい批判的に見てもらう

AIに「ありえないぐらい批判的に見て」って頼むとき、欲しいのは、自分では見落とした穴なんですよね。

たとえば、提案書を自分で読んでいると、「この説明で分かるでしょ」と思いやすい。自分は前提を知っているので、読む人がまだ説明されていない話についていけず、途中で置いていかれていても、頭の中で補えてしまう。

そこでAIに、お客さんの立場から疑ってもらう。

「なぜ今やるのかが伝わらない」「担当者の作業がどこまで増えるのか書いてない」「この数字はどこから来たのか」。そういう指摘なら、次に確かめることが見えます。

でも、「厳しく」と頼んだら、厳しい言い方の文章が返ってきただけ、ということもありますよね。「説得力がありません」「差別化が不十分です」。いや、どこの話よ、と。

言い方が強いと、なんとなく当たっている気がしてしまう。そこは一回止まって見たいです。

指摘するなら、該当する文章や画面を挙げてもらう。それが誰をどう困らせるのか、理由も付けてもらう。確認できていないことは、確認できていないと書いてもらう。

この条件を入れると、こちらも指摘を選びやすくなります。「確かに、ここは直そう」「これは前のページに書いてあるので採用しない」「この数字は元データを見直そう」。それぞれ次の動きが違う。

全部をそのまま直す必要はないです。AIが見落とすこともあるし、こっちの目的と違う立派な改善案を出してくることもあるので。

あと、直したあとに、同じ箇所を見てもらうところまでセットにしたい。文言を変えたから解決したつもりになっていても、読む人の疑問は残っているかもしれない。

批判を受けるって、ちょっと面倒です。自分で良いと思って出したものですしね。だから、誰かに見せる前にAIで一度穴を探しておくと、出すときの迷いを減らせると思います。

次に見てもらうときは、「厳しく」に一文足してみてください。「指摘する箇所と、その根拠も出して」。そこまで出てきたものを読んで、直すものを自分で選びましょう。

一緒に渡せる指示文

この提案を採用しない理由を、想定読者【読者】の立場から厳しく点検してください。目的は【目的】です。重大な問題から最大5つ。指摘ごとに該当箇所、根拠、読者への影響、修正案を示してください。根拠のない欠点を作らず、不明な点は確認事項にしてください。問題が見つからない場合は、その旨を伝えてください。

元のタスク：ラジオ📻ありえないぐらい批判的な視点でfbさせる

3. ある経営者の名前を借りて、見る基準を変える

「ある経営者ならどうする？」ってAIに聞いてみる。こういう聞き方は、自分が当たり前にしている基準を、一回外すために使えると思うんですよね。

たとえば、説明をたくさん詰めたページがあるとします。作った側としては、どれも必要に見える。機能も書いた。特徴も書いた。導入の流れも、会社の紹介も入れた。

でも、初めて開いた人は、最初の画面でどこを見ればいいのか分からないかもしれない。

そのとき、「もっと綺麗にして」だと、色とか余白の話で終わることがある。僕なら、まず「この画面で、一番見てほしいものは何？」を考えたいです。

申し込んでほしいなら、その前に何が分かっていれば申し込めるのか。資料を読んでほしいなら、読むと何を判断できるのか。そこを決めると、最初に見せるものも変わります。

人物の名前を使うのは、その問いを出すきっかけとして面白い。ただ、返ってきたものはAIの案なので、ある経営者本人がこう考えた、という話にはしない。名前がつくと正しそうに見えるけど、最後に確かめるのは目の前の画面です。

仮に、AIが文字を半分にして、余白を広くした案を出してきたとします。ぱっと見は綺麗になった。でも、料金に含まれる範囲まで消えていたら、それは困る。

減らせばいいというものでもないんですよね。初めて使う人が迷わず進めて、必要なことも分かる。その状態になっているかを見る。

比べるときは、変更前と変更後を並べたいです。どこを最初に見たか。次に何をすると思ったか。実際にボタンを押して、その先まで進めるか。

「最初に見る場所が決まった」「説明を探し回らずに済んだ」。使う人からそう返ってくれば、どこを残したいかも分かります。

いま作っている画面や資料で試すなら、「この人が次に何をするかまで考えて、変える箇所を一つ選んで」と続けてみる。

出てきた案を、変更前と並べて見る。名前の力を借りたあと、自分の目で選ぶところまでやってみてください。

一緒に渡せる指示文

ある経営者ならどこを変えるだろう、と考えて、画面の見せ方を見直す案を出してください。これは思考実験です。本人の発言や判断を再現したとは扱わないでください。利用者は【利用者】で、この画面の目的は【目的】です。最初に注目すべきものと、次に取る行動が伝わるかを確認し、効果が大きそうな変更を一つ提案してください。必要な条件や説明は削らず、変更前後を比べる確認方法も添えてください。

元のタスク：ラジオ📻ある経営者ならどうする？で綺麗にする

収録前に

3本とも、そのまま短く話すことも、最近の実例を一つ足して広げることもできます。実例を足す場合は、あなたが実際に見て判断した場面を選んでください。顧客名や未公開の数字は本文へ入れていません。

話し言葉の調整には、本人の公開記事にある、具体例から判断へ進む流れと文の長短を参照しました。古い記事の事業数値・経歴・強い表現は今回へ持ち込んでいません。スピード感のある人が好きです。・「とりあえずやってみる」ができない人へ
850字の候補 / 原文を保持・採用前

動画を3分前後にする場合の、短い原稿案

元台本をそのまま撮るなら、LPの「3分」表記を見直すのが自然です。3分を優先する場合に比べられるよう、短い候補も用意しました。 元のNotion台本と、原文を収めた撮影画面は変更していません。

読み上げ部分は850字です。毎分300〜400字と仮定すると約2分08秒〜2分50秒（間・画面説明を除く）。以下は今回作った提案稿です。収録時間は本人の話す速さと画面を見せる間で変わるため、採用前に一度通して計測してください。

読み上げ原稿

「AIツールを導入したのに、使っているのは一部の社員だけ」 「業務を自動化したはずなのに、最後は人が手作業でつないでいる」

従業員10名以上の会社を経営していて、こんな悩みはありませんか。

一つの作業が速くなっても、その前後がつながっていなければ、仕事全体は変わりにくい。社員によってAIの使い方や成果物の精度が違えば、会社全体への広がりも止まってしまいます。

必要なのは、自社の課題を見つけ、AIで改善できる人材と、複数の業務をつなぐ仕組みです。

企業のAI活用と業務改善を支援する自社のプログラムが、研修サービスです。

研修サービスでは、eラーニングでAIの基礎や原理原則を学びながら、自社が実際に抱えている業務課題の改善に取り組みます。

研修期間中は、受講者一人ひとりがAIコンサルタントに相談できます。

「この業務は、どうAI化すればいいのか」 「作ってみたけれど、うまく動かない」

実務でつまずいたところを相談しながら、業務の改善やAIエージェントの構築、前後の工程をつなぐ仕組み化まで進めていきます。

目指すのは、研修が終わったあとも、社員自身が課題を見つけ、自分たちで改善を続けられる状態です。

たとえば、バックオフィスの担当者を新たに採用する予定だった企業では、日程調整などの定型業務をAIで自動化しました。任せられる業務が広がり、予定していた採用計画を見直すことにつながっています。

AIを使う場面が増えるほど、社内情報の扱いや、生成された内容の確認も欠かせません。会社として安全な使い方を学び、活用する仕組みを整えていく必要があります。

現在、動画をご覧いただいた方を対象に、AI組織づくりの個別相談会を開催しています。

専門のコンサルタントが、御社のAI活用状況や業務課題を伺い、どの業務から改善するか、どんな仕組みをつくれるかを一緒に整理します。

自社では、どこまでAI化できるのか。社員が安全に使える体制を、どうつくればいいのか。

動画下の予約ボタンから、面談日程をお選びください。 ご参加をお待ちしています。

元台本から変えた箇所

バックオフィス事例は元台本の記載をもとに短くしたもので、今回あらためて顧客側の実績資料を検証したものではありません。採用する事例・数値・素材は、原稿担当者と確認してください。

原文と撮影画面

この案はローカル保存のみ。台本の差し替え・LPの表記変更・公開は行っていません。