面倒な報告を自動化する

自分でAIに指示を出してツールを動かす段階から、一歩先へ進みます。この講義のテーマは「面倒な報告の自動化」です。毎朝決まった時間に、最新のデータから自動でレポートが作られ、チャットに届く。そんなツールを自分の手で作るための仕組みと、実践のコツを学びます。

前半では、講師が毎日使っている2つの報告自動化ツールを実物として見ながら、報告の自動化がなぜ「人生を変える」ほど重要なのかを掘り下げます。後半では、自動化ツールに共通する4つのパーツ(トリガー・ソース元・処理する場所・届ける先)と、質の高い報告を安定して届ける3つのコツを解説します。

ここから技術的な話が増えますが、細部を一度で理解する必要はありません。講師自身「1回の説明で理解できた人にお会いしたことはない」と述べています。大事なのは大枠の概念をつかむことです。わからないことはメモしておき、後でAIに聞いて調べる。それがこの教材全体で推奨されている学び方です。

手作業の自動化、その先へ

第1章の締めくくりとして、受講生は自分の仕事に合わせた図解作成Skill(AIに手順や判断の型を教え込む再利用可能な指示書)を作り、図解をURLで世界に公開できるようにしました。ゼロからHTML(Webページを作る言語)の図解を作ればとても時間がかかりますが、今はワンコマンドで一瞬で作れます。AIの力は凄まじいものです。

しかし、まだ面倒は残っています。この図解Skillは、Cursor(AI搭載のコードエディタ)ならスラッシュコマンドでSkillを呼び出し、「こんな図解を作りたい」と指示して初めて動きます。人間がいないと動かないのです。

講師はこの状態を料理に例えています。材料と調味料が揃ったミールキットで、美味しい手料理をサッと自分の手で作れるようになった状態です。しかし本当は、自分で作らなくても美味しい料理が運ばれてきてほしいはずです。更新が必要な情報を扱うSkillは、都度人間がコマンドを打たなければなりません。同じ手順を繰り返すのなら、自動化の出番です。この講義では「手作業でAIに何かをさせる」のその先に行きます。

前提となる10のAI-Driven Rules

この講義の内容は、第1章で学んだ10のAI-Driven Rules(AI時代の仕事の原則)の上に成り立っています。要点を振り返ります。

1. 90点から100点の戦いに備えよ — AIなら90点のものはすぐできます。残り10点に全エネルギーの9割が費やされるため、最後の詰めを行う武器を自分で作ります。
2. 理解できないものは作るな — 「なぜこう動くのか」と問い続け、ブラックボックスを残さないことが付加価値を生みます。
3. 自分の武器を自分で作れ — 汎用ツールに業務を合わせる時代は終わり、面倒な仕事を消す専用ツールを自分の手で作ります。
4. 図解で認知コストを下げろ — 複雑な構造も図にした瞬間に全体像が見え、他者にもそのまま伝わります。
5. 議論する前にプロトタイプを作れ — 言葉で伝えれば必ず劣化します。動くものを作って見て議論します。
6. AIが見る情報を整えろ — AIの出力の質は渡した情報の質で決まります。情報を1箇所に集めるSSoT(Single Source of Truth。信頼できる唯一の情報源)を厳守します。
7. スキルを育て続けろ — 手順や判断の型をスキルとして残すと、AIの精度と幅が広がり続けます。
8. 抽象指示より模範解答を作れ — 言葉を尽くすより「これが正解」を1つ見せる方が、AIの出力は格段によくなります。
9. スピードを出すな、対話しろ — 解像度が低いまま突っ走ると行き詰まってやり直しになります。
10. 1クリックを減らせ — 操作を1つ減らすことへの執着が、ツールの使い心地を決定的に変えます。

この教材では、以降の解説の中で特にルール1・2・5・6・8・10を手がかりとして繰り返し参照していきます。

実例1|コミットレポートツール「コミネコ」

「議論する前にプロトタイプを作れ」の原則どおり、講義ではまず実物のツールが2つ紹介されました。どちらも、同じ時間に最新の情報をもとに自動で図解が作られ、講師にチャットで送られてくるツールです。

前提 — すべての情報をGitで管理する

1つ目のツールには大前提があります。講師のチームは、すべての仕事をGitリポジトリ(変更履歴つきでファイルをまとめて管理する保管庫)で管理しています。ただの共有フォルダと違うのは、誰がいつどんな作業をしたのかがすべて記録されている点です。

これは「AIが見る情報を整えろ」の実践です。同じ情報があちこちに書かれている状態をなくすSSoTを守るために、情報をGitで管理します。講師は「可能であればすべての会社がすべての情報をGitで管理すべきで、すべての社会人がGitを覚えるべきだ」とまで述べています。勤務先でいきなり全員導入は難しくても、自分のプロジェクトで使えるなら使う価値があります。正確には、Gitをチームで共有しやすくするサービスGitHub(ギットハブ)を使えるなら、使った方がよいとされています。

具体例として、講師のチームが運営する学習アプリの開発現場が紹介されました。新しいクイズを作る人と、アプリ自体を改修する人が、1つの共有フォルダで自由に作業すると、気づかないうちに相手の変更を上書きしてしまいます。Gitならブランチという機能で、ある時点のファイルから分岐して作業できます。クイズのシリーズを1つ作り終えたら、あるいはバグを直したら、マージ(分岐した作業を合流させること)する。これを繰り返すことで安全に並行作業ができます。作業がバッティングしたときはGitが教えてくれますし、今はその衝突もAIが99%解決してくれます。

Gitで管理するのはプログラムだけではありません。会議をしたら議事録もリポジトリに上げ、定期的に整理整頓します(整理整頓もAIで自動化できます)。「この前の会議で話したことは何だっけ」と人に聞く必要はなくなります。すべての情報がリポジトリにあれば、Cursorのチャットで聞けばわかるからです。さらに、Cursorを開かずにチャットで情報を取り出すこともできます(次の講義の内容です)。

コミネコができること

1つ目のツールはコミットレポートツール、講師の命名で「コミネコ」です。誰がどんな作業をしたのかを、自動で図解にして報告してくれます。

デモはチャットツールSlack(スラック)の画面で行われました。ただし講師は「伝えたいのはSlackのツールではなく、いかにAIで自動化するかだ」と強調しています。Slackは連携面で優れているため例に使っただけで、TeamsやLINEなど別のツールでも、Windowsでもスマホだけでも考え方は同じです。

コミネコは毎朝7時に、自動で作られた図解レポートの画像をSlackに届けます。新聞の朝刊のように、365日休まず同じ時間に届きます。図解はデザインまで整ったHTML製で、第1章で受講生が作ったものと同じ種類です。

仕組みの土台はGitです。チームは原則すべての作業をGitリポジトリ上で行うため、Gitを見れば誰が何をやったかすべてわかります。この「誰が何をやったか」の単位をコミットと呼びます。しかしコミットは膨大で、すべて読むのは困難です。そこでコミネコが、誰がどのプロジェクトで何をしたのかをビジュアルでまとめます。技術的な内容も「要するに何を変えたのか」という簡単な言葉に変換されるので、わかりやすいのです。

レポート画像は1枚ではありません。ブランチごとの進捗、時系列のタイムライン、そして毎日1つ何かを学べる「ワンポイントTips」も含まれています。設定はSlackのチャンネルごと(チャンネル=1つのプロジェクトに相当)に行います。

効果は具体的です。リモートで作業を依頼したとき、「昨日お願いしたことは終わっているのか」を確認したくなります。以前はチャットで聞くか、GitHubを見に行くしかありませんでした。今はコミネコが届けてくれるので、誰がいつ何をしたかがサマリーで一目でわかります。コミネコは現在10個のプロジェクトで動いており、作業報告そのものが不要になりました。

もう1つの効果は「健全な緊張感」です。前日に「15時までにやっておきます」とやり取りしたのに、コミットが18時なら、間に合わなかったことが明らかになります。期限を決めても結局守られない、という組織のブラックボックスをなくせるのです。

実例2|進捗可視化ツール

コミネコは「誰が何をやったか」をサッと把握するツールでした。2つ目は、プロジェクト全体の進捗を可視化するツールです。作業の記録だけでは、全体として順調かどうかは判断できません。このツールはコミネコと同じく、進捗管理のダッシュボード(状況を一覧できる画面)の画像をSlackに投稿してくれます。

講師のチームはメディアを運営しており、企画を考え、原稿を作り、動画を作り、この日までに公開するという目標があります。いわゆるプロジェクト管理です。以前は小難しいスプレッドシートを見に行くか、口頭で確認するしかありませんでしたが、今は順調かどうかが一目でわかります。

見た目はシンプルで、プロジェクトの進捗が信号機の色で表示されます。緑は順調、黄色はちょっと心配、赤はやばい。パッと見た瞬間にわかります。

重要なのは、このツールはAIを使って作られたものの、動くときにはほとんどAIが動いていない点です。どの色に分類されるかは、プログラムの方が正確だという理由で、プログラムで機械的に決まっています。AIが動くのは一部分だけで、進捗を見て「次にやるべきこと」を提案する箇所です。黄色や赤のプロジェクトがあれば、何が遅れていて何をすればいいかをまとめて提案してくれます(あくまで参考情報という位置づけです)。この設計思想は、後述するコツ3「ブレをコードで止める」の核心です。

報告には3つの種類がある

報告には、いくつか種類があります。

どれであろうと、「情報を集めて、整理して、まとめて、送る」という同じ作業が繰り返されます。Skillを使えばかなり自動化できます。それが自動で送られてくれば、もっと効率が上がり、もっと仕事が捗ります。

紹介された2つのツールは今も動き続けています。講師の例えでは「冷蔵庫みたいなもの」、電源を入れたら勝手に冷やし続けてくれる存在です。2つのツールは受講生に共有され、参考にしても、そのまま使っても構わないとされています。

報告の自動化は人生を変える

毎週の売上報告を上司に出している場面を考えます。指示されたからやっている面倒な仕事かもしれません。しかしその報告がなければ、上司は現場で何が起きているかわからず、その上の部長や役員にも情報が伝わりません。誰も正しい判断ができなくなります。先週から売上が30%ガクッと落ちたのに報告を怠れば、上司もその上も何も手を打ちません。報告は面倒でも、意思決定のために必要不可欠な仕事なのです。

仕事の3ステップ — 認知・意思決定・実行

少し大きな視点で整理します。仕事には3つのステップがあります。

1. 認知 — 何が起きているかを知ること
2. 意思決定 — 次に何をするかを決めること
3. 実行 — 実際にやること

飲食店で考えると、認知は「今月の売上が先月より15%落ちている」と知ること。意思決定は「ランチメニューを見直そう」と決めること。実行は実際にメニューを作り変えることです。

多くの人が頑張るのは実行です。上の人が決めたことを一生懸命やる。大事なことですが、どんなに手を早く動かしても、意思決定が間違っていたら元も子もありません。売上が改善する見込みのないメニュー変更に力を注いでも意味がないのです。そしてさらに上流、意思決定が生まれる場所が認知です。売上が落ちていることに気づいていなければ、「メニューを見直そう」という判断自体が生まれません。

講師の主張を一言でまとめます。私たちは目で見る情報と耳で聞く情報によって意思決定し、行動している。つまり「何を見て何を聞くかですべてが決まる」ということです。3つのステップの中で最もレバレッジが効く(改善したときの効果が大きい)のは認知です。

認知の速さがすべてを変える

売上が10%落ちた事実に、1ヶ月後に気づくのか、1週間後か、1日単位か。売上には日々のブレがあるので、1日単位で一喜一憂する必要はありません。問題は「今日の売上の状態がパッとわかるようになっているかどうか」です。

毎日売上をチェックしていれば、ある曜日だけ売上が下がることに気づけます。なぜだろうと考えると、近くの大きな会社で特定の曜日に社内イベントがあり、ランチに出かける人が減っているからだとわかる。ならばその曜日は、いつもと違う客層にアピールする日替わりメニューにしよう、と考えられます。認知を変えれば、その先がすべて変わるのです。

進捗可視化ツールも同じです。遅れ始めたときに黄色信号が出れば「どうしようか」と考えられます。赤ランプが点いてからでは、やれることが限られてしまいます。

起きなかった問題は気がつけない

落ち着いて考えれば認知が重要だとわかるのに、私たちはその価値を低く見積もってしまいます。原因は明らかで、「起きなかった問題は気がつけない」からです。

報告が自動で届くようになれば、認知でき、対処できます。しかし届かなかった世界で何が起きていたかは、誰にもわかりません。だから報告自動化の効果は実感しづらいのです。「作業時間が浮いた」はわかりやすい効果です。しかし本当の効果は、起きなかった事故、起きなかった炎上、取り逃がさなかった売上といった、見えない成果の方がはるかに大きいはずです。さらに、現状を認知することで「もっとこうしたらいいのでは」というアイデアをひらめくチャンスも増えます。新しいアイデアを生めなかった損失も、目には見えません。

自動化ツールを支える4つのパーツ

AIに「自動でレポートして」と頼めば作ってくれます。しかし何をやっているかわからないままでは、「理解できないものは作るな」に反します。運良く動いても90点で詰み、最後の10点を詰められません。報告自動化ツールには共通の仕組みがあるので、まず全体像を押さえます。

毎日報告を作ってくれるような自動化ツールには、必ず4つのパーツがあります。トリガー・ソース元・処理する場所・届ける先。この4つだけです。講師は料理に例えています。伝票を取って、冷蔵庫から材料を取って、キッチンで調理して、テーブルに運ぶ、という流れです。

トリガーは「いつ、何をきっかけに動くか」の設定です。トリガーなしにツールが勝手に動き出すことはないため、トリガーを設定する場所が必ず必要です。

ソース元はデータの取得先です。冷蔵庫に新鮮な食材が必要なように、新鮮なデータがなければ意味がありません。同じデータからは同じアウトプットしか出ないからです。

処理する場所では、取ってきたデータを加工し、生のデータに意味を持たせます。

届ける先は完成した報告の送付先です。チャットでもメールでも、設定すれば自作のアプリにも送れます。

コミネコを4つのパーツで分解する

それでは、コミネコがこの4つのパーツでどう動いているのかを順に見ていきます。

トリガー — GitHub Actionsで毎朝7時に動かす

コミネコには「毎朝7時に動く」というトリガーがあり、GitHub Actions(ギットハブ・アクションズ)という機能で動いています。

前提を整理します。GitHubはGitを共有するためのサービスで、文章やコードの管理を楽にしてくれます。ほとんどの企業が自分たちのソースコードをGitHubに置いています。注意したいのは、GitとGitHubは別物だという点です。Gitは世界中で使われている無料のオープンソース(誰でも使える公開ソフト)のツール。GitHubはそのGitを使いやすくした、現在はMicrosoft傘下の巨大なサービスです。GitHub ActionsはGitの仕組みではなく、GitHubというサービスが用意してくれている便利な仕組みです。

GitHub Actionsは、簡単に言えばトリガーを動かせる機能です。「毎朝7時にあることをする」と登録できる場所、というイメージで十分です。実際は時間だけでなく、「新しいコードが上がってきたら自動でレビューする」など、いろいろなトリガーを設定できます。

では設定はどこでするのか。ブラウザでGitHubの設定ページを開いて行う、と思うかもしれません。それも間違いではないのですが、正確には違います。GitHub Actionsの設定は、自分の管理するリポジトリの中に設定ファイルを置くことで行います。この設定ファイルはYAML(ヤムル)形式という、世界的に使われている書き方で書きます。見慣れないだけで、誰でもすぐ理解できるくらい簡単なフォーマットです。

手順としては、GitHubが指定する書き方でYAMLファイルを書き、GitHubにアップロードします。このアップロードをGitではプッシュと言います。手元でセーブしただけでは他の人はそのデータを使えないので、プッシュするのです。YAMLに「朝7時にこういうことをして」と書かれていれば、翌日から毎朝7時に実行されます。書き方は一見複雑で「作れる気がしない」と感じるかもしれませんが、AIに言えば全部一瞬で作ってくれます。

設定ファイルがGit管理されている利点は、誰がいつどんな変更をしたか履歴に残ることです。誰かが(あるいはAIが)設定を間違えて動かなくなっても、うまく動いていた状態にすぐ戻せます。

もう1つ重要なのは「どこで動くか」です。動く場所はGitHubというサービス上、つまりGitHub社が管理しているサーバー(要するにどこかにあるパソコン)の上です。自分の手元のパソコンではありません。

トリガーを設定できる場所はGitHub Actionsだけではありません。n8n・Zapier・Makeのようなワークフローツール(複数のサービスをつないで自動処理を組めるサービス)を使えば、そのサービス上が動きの起点になります。Cursorにもオートメーション機能があり、トリガーになれます。トリガーを設定できるサービスは山ほどあり、使い方も日々変わります。しかし「トリガーがある」ということだけは変わりません。

ソース元 — APIキーという鍵でデータを取ってくる

コミネコに必要なデータは、各リポジトリのコミット、つまり「どのリポジトリで誰がどんな作業をしたか」です。コミネコはGitHub上の専用リポジトリで動きますが、権限の関係で、他のリポジトリのコミットを勝手に取ることはできません。会社の重要な情報はプライベートリポジトリ(関係者以外は見られない非公開の保管庫)で管理され、第三者がいつでも見られたら危険だからです。そこで、他のリポジトリにアクセスするための「鍵」を発行して渡しておきます。

ここでAPI(他のサービスから情報を取ってくる仕組み。アプリ同士をつなぐ窓口)という考え方が出てきます。誰でも情報を取得できる公開APIもありますが、基本的によく使うのは鍵が必要なAPIです。このAPIを使いこなせるかどうかで、AI活用の幅はぐっと広がります。小難しい知識は不要です。GoogleカレンダーやGmail、チャット、タスク管理ツールといった他のサービスから、自分がパソコンやスマホでアクセスしなくても情報を取ってこられる鍵を、サービスごとに発行できる。そう理解していれば十分です。この鍵をAPIキーと言います。

GitHubには「この鍵を使ってね」と登録できる場所があり、そこに置けば安全に管理され、流出しません。この鍵があるから、コミネコは他のリポジトリからデータを持ってこられるのです。

処理する場所 — サーバー上でAIが図解を作り、画像化する

流れを整理します。GitHub Actionsでトリガーが動くと、APIキーを使ってAIが動くように設定されています。コミネコのAIはClaude(クロード。Anthropic社のAI)です。AIには「何をしてほしいか」の指示が事前に書かれており、対象リポジトリからデータを持ってくることも指示されています。処理をしている場所はGitHub上のサーバーで、そこでAIが動きます。

料理の例えに戻ると、キッチンでシェフが働いているイメージです。シェフは鍵のかかった冷蔵庫から、鍵を使って食材(誰がいつ何をしたかというコミット情報)を取り出し、キッチンに並べます。ここから調理の時間です。

調理は段階を踏みます。まず、Gitから取得した生のデータ(たとえばドキュメントを更新したときの記録)を、人間がわかりやすい言葉に変換します。次に、HTML・CSS・JavaScriptで図解を作ります。受講生は図解を手元のパソコンで作りましたが、コミネコの図解はGitHubのサーバー上、つまり世界のどこかの別のパソコンの上で作られます。図解を作っているのはAIで、「こんな図解にしてほしい」という指示と模範解答が渡されています(ルール8の実践です)。

図解ができたら、画像に変換します。スマートフォンのスクリーンショットと同じことを、サーバー上のパソコンでもできるのです。そのためのツールがPlaywright(プレイライト)です。人間がSafariやChromeを使うように、AIやプログラムが使うブラウザだと思ってください。Microsoftが無料で提供しており、これで図解のキャプチャを撮ります。

届ける先 — フォーマットに沿ってSlackへ投稿する

キャプチャという料理ができたら、テーブルに運びます。コミネコの届け先はSlackです。ただしSlackには勝手に投稿できません。社内ツールやLINEに知らない人がいきなり投稿してきたら怖いのと同じです。そこでここでもAPIキーが必要です(厳密には「認証」が必要で、APIキーはその一手段ですが、ここではAPIキーという理解で問題ありません)。Slackに投稿できる鍵を渡しておくと、AIがその鍵でキャプチャをSlackに送信してくれます。

ただし、鍵を持っているだけではうまく投稿されないケースがあります。投稿の仕方にフォーマット(決まった形式)があるからです。Googleカレンダーへの自動登録に「こんな情報を送ってね」という形式が決まっているのと同じで、Slackにもタスク管理ツールにもフォーマットがあり、間違えるとエラーになります。AIは何も言わなくてもいい感じに仕事をしますが、「このフォーマットで送って」という指示があると、より正確になります。

こうした技術的な説明は、自分でやってみないと100%は腹落ちしません。現時点では「なんとなくわかる」で大丈夫です。コミネコのソースコードは受講生に共有されるので、クローン(リポジトリを手元にダウンロードすること)して、AIに解説してもらうのが一番の学びになります。

進捗可視化ツールの仕組み — AIとプログラムの使い分け

2つ目の進捗可視化ツールの仕組みは、基本的にコミネコと同じです。トリガーはGitHub Actionsにあり、YAMLファイルは対象プロジェクトの情報が置かれたリポジトリの中にあります。ソース元はLinear(リニア)というタスク管理ツールです。講師は「使いやすくておすすめ」としつつ、他のタスク管理ツールでも問題ないとしています。これもAPIキーを登録しておくことで、メンバーの仕事の情報を取得できます。

ここで、理解が一段深まる説明がありました。コミネコの説明では簡単のため「トリガーでAIが立ち上がる」と表現されましたが、正確には違います。トリガーでプログラムが動き、そのプログラムがAIを起動しているのです。起動後はAIに任せています。

進捗可視化ツールでは、さらにAIの出番が絞られています。タスク管理ツールからの情報取得はプログラムが行い、信号機の色の図解もプログラムが機械的に作ります。AIの判断は一切入っていません。AIが動くのは「どうすべきか」という提案文を考える部分だけで、その文章をプログラムが図解の型に流し込んでいます。

なぜこう作り分けるのか。AIとプログラムには次の違いがあるからです。

難解なデータをわかりやすい言葉にするような柔軟な仕事は、プログラムにはできません。一方でAIには出力がばらつくデメリットがあります。スキルの整理や模範解答、AIにプログラムを動かさせる工夫で安定させられますが、100%ではありません。プログラムは柔軟ではない代わりに、同じことをバシッとやってくれます。使い分けの考え方は、コツ3で詳しく扱います。

図解ができた後はコミネコと同じで、Playwrightでキャプチャを撮り、Slackに送ります。

コツ1|完成形の絵から作る

ここからは、実際に報告自動化ツールを作るときの3つのコツです。1つ目は「完成形の絵から作る」、2つ目は「専門家に磨かせる」、3つ目は「ブレをコードで止める」。なお、細かい技術は講義では扱わず、ドリルの積み重ねと「作りながらAIに聞く」ことで身につける方針が示されています。

コツ1。報告を自動化したいと思ったとき、最初にやるべきことは仕組み作りではなく、最終的な見た目を作ることです。「抽象指示より模範解答を作れ」(ルール8)の実践です。コミネコも進捗可視化ツールも、「どんな絵が見られればいいのか」を考えるところからスタートしています。開発の最後に見て「なんか違うな」と思ったら、すべてやり直しになるからです。

HTMLでレポートを作る場合、必ず最初にAIに伝えるべき指示があります。「モダンなフレームワークを使って作って」です。より厳密には「Tailwind CSS(テイルウィンドCSS)を使って」と言うのがよいとされています。「モダンなフレームワークで」と言えば、ほぼ間違いなくTailwind CSSが使われます。HTMLで図解を作るなら必ずTailwind CSSを使うべきで、特に悩む理由はない、というのが講師の推奨です。

見た目を考えるときは「議論する前にプロトタイプを作れ」(ルール5)です。最低限、自分が見るなら自分がどうなりたいのか、誰かに見せるならその人にどうなってほしいのか。ここだけは音声入力でもいいのでAIに伝えます。これだけは自分でやるしかありません。

そのうえで、完成形の絵には次のポイントがあります。

1. パッと見て2秒でわかるようにする — 報告にたくさん書かれていると、結局読まれなくなります。優れた報告とは、一番知りたいことが2秒でわかるものです。本当に知りたいことは一言で言うと何なのかを突き詰め、進捗可視化ツールの信号機くらいシンプルにするのがおすすめです。
2. 画像で送る — リンクで送ることもできますが、1タップ多いだけで見なくなります(ルール10「1クリックを減らせ」)。画像で届けば、開く手間なく認知できます。
3. スマホファーストで作る — パソコン前提の横長で作ると、スマホで見づらく、外出先でパッと確認できません。スマホでも見やすいサイズで作ります。

コツ2|専門家に磨かせる — サブエージェントレビュー

コツ2を一言で言えば、「AIにレポートを作らせたら、別のAIにレビューさせよう」です。そのための概念がサブエージェントです。

第1章では、AIには3つの壁があることを学びました。コンテキストウィンドウ(AIが一度に扱える情報量の上限)、アテンション(注意力。多くのことを同時にやらせると精度が落ちる性質)、オートリグレッション(自己回帰。直前までの自分の出力に引きずられる性質)です。サブエージェントは、この壁を越えるための技術の1つです。

サブエージェントは名前のとおり「サブ」のエージェント、つまりAIです。本体で仕事をしているAIが、自分の部下を呼び出して仕事をお願いするようなものです。部下なので別人です。サブエージェントは仕事を依頼された時点で初めて情報を聞かされるため、動き始めた瞬間は頭がフレッシュな状態です。それがよいのです。

なぜ自分でレビューさせてはだめなのか

AIはインプットは得意ですが、アウトプットには大きなエネルギーを使っています。文章を出すときは「次の単語は何がいいか」を1つずつ考えています。その結果、AIは一貫性を保とうとします。一度自分がやった仕事は正しいという前提で、話を続けようとするのです。AIに図解や模範解答を作らせて「これ問題ない?」と聞くと、「問題ない」と答えやすい仕組みになっています。悪気のあるなしではなく、生成AI(LLM)の仕組みです。

人間も同じです。自分で文章を書いていると良し悪しがわからなくなり、人に「どう思う?」と聞きたくなります。それをAIにもさせるのがサブエージェントレビューです。最新のAIは1回のチャットでも非常に優秀ですが、それでも限界はあります。

実践のやり方

講師の実践はこうです。CursorやClaude Code(コマンド操作型のAIコーディングツール)で計画を作らせます。Cursorならプランモード(実装せず計画だけを立てるモード)を使います。そしてその計画をサブエージェントにレビューさせます。作ってからよりも計画段階の方が変更が少なく、効率的に進められるからです。講師はこれをほぼ必ず行っています。

よく使うのは、UI/UXデザイナーとエンジニアのサブエージェントをそれぞれ起動する方法です。見た目・使い勝手の観点と、仕組みの観点の両方で、頭がフレッシュなAIにレビューさせると、的確な指摘を受けられます。正直面倒に感じるものの、やるたびに「やってよかった」と思えるとのことです。新しいツールや機能を作るとき、そして報告ツールを動かす仕組みの中にも、サブエージェントレビューを組み込むことが推奨されています。具体的には、トリガーで動き出すAIへの指示の中に「サブエージェントを起動してレビューして」と書いておきます。

ただしマストではありません。AIを動かす分、費用も時間も多少かかります。とはいえ自動で作られるものなので、速さは気になりません。作成が1〜2分遅くなっても、クオリティが高く間違いがない方が価値があります。

実践のポイントは次のとおりです。

• できればHTMLにする前に、一度文章だけで報告を作らせてレビューさせる。上流でレビューするほどやり直しが減り、品質が上がります。
• 指示は「レビューして」ではなく「サブエージェントにレビューして」と明示する。「自分でレビューして」と言ったときとは性能がまったく違い、ダメなものをダメと言ってもらえます。人間の部下は上司に言いづらいことに気を使いますが、AIは遠慮なく指摘してくれます。
• 受講生が取り組むドリル教材の問題も、何度もサブエージェントのレビューを受けて作られています。

仕組みから理解する

なぜ修正させないのか。サブエージェント(部下)が指示を受けて作業し、アウトプットを持ってくるまでのプロセスを、指示した側のAIは見ません。見ないことによって、指示側のコンテキストウィンドウを節約できるのです。上司が部下に仕事を頼んだのに、後ろからつけ回して一挙手一投足を見ていたら、お願いした意味がなく、自分の仕事もできません。それと同じです。何を依頼するかは親(上司)にあたるAIが考え、依頼したら結果をもらうだけです。

アテンションの面でも効果があります。AIにいろいろなことを同時にやらせると性能が落ちるため、レビューだけに集中させることで、レビューの性能が上がるのです。

一方で注意点もあります。サブエージェントは全体の文脈を知りません。むやみに起動して仕事をさせると、効率や性能がかえって下がることもわかっています。最も活躍する場面の1つがレビューです。この考え方は報告ツールに限らず、AI活用のあらゆる場面で必ず使うべき概念だとされています。

最後に、スキルとの組み合わせです。レビューで見てほしい観点が決まっているなら、レビューのスキルを作り、サブエージェントにそのスキルを動かしてもらうのがおすすめです。サブエージェント自体も「レビュー担当」「デザイン担当」のように定義できますが、定義は極力簡潔にし、具体的な仕事内容はスキル側に書きます。スキルなら他のサブエージェントからも呼び出せて、使い勝手がよいからです。本当に高い品質にしたい場合は、細かくサブエージェントでレビューします。

コツ3|ブレをコードで止める

コツ1で完成形を決め、コツ2で専門家に磨かせました。最後は、動き続けるツールの品質を安定させるコツです。

報告自動化ツールは、プログラムで作る方法と、AIに柔軟に仕事をさせる方法があります。AIが賢くて柔軟なら全部AIで動かせばいい、と思うかもしれませんが、そうではありません。AIの難点は「たまに壊れる」こと、つまり出力がブレることです。

毎日の売上報告ツールを作り、模範解答も渡したとします。それだけだとブレます。月曜日は正しく出せた。火曜日もできた。でも水曜日は失敗してエラーになった、もしくは見た目が崩れていた。木曜日には戻ったが、金曜日にまた壊れた。そういうことが起きるのです。AIはすごく賢いのに、ガチャのように、動かすたびに出力がブレてしまいます。

このAIの苦手をサポートするのがプログラムです。プログラムがAIの仕事をサポートするやり方は3つあります。

① チェックする — バリデーション

1つ目はチェックです。ここで新しい言葉、バリデーション(入力や出力が正しい形式かをプログラムで機械的に検査する仕組み)が登場します。身近な例は、Webサイトのメールアドレス入力欄です。アットマークが入っていないと赤くなり、「正しい形式で入力してください」と表示されます。あれがバリデーションで、AIは動いていません。プログラムが機械的にチェックしているだけです。

この機械的チェックが非常に重要です。超高品質なものを作りたいときに限られますが、「バリデーションできるものはすべてバリデーションした方がいい」とされています。機械的チェックは一瞬で実行されます。やり方は、バリデーションのプログラムをあらかじめ作っておき、AIにそのプログラムを動かすように指示を書いておくことです。出力の形式は正しいか。必要な項目は全部入っているか。たとえばダッシュボードのHTML図解なら、信号機の3色のどれかが必ず入るはずなので、それ以外の紫などが入っていないかを機械的に確認できます。文字数が膨大になっていないかも確認できます。バリデーションの価値は今はわかりにくくても、AIに高品質なアウトプットを求めるほど、その重要性に気づいていくはずです。

② 型にはめる

2つ目は型にはめることです。AIは柔軟な思考が強みですが、プログラムは型にはまったことを素早く行うのが得意です。同じたい焼き機で焼けば、すべて同じたい焼きの形になります。そうした繰り返し作業にはプログラムが向いています。

売上報告の自動化で、毎回AIに「いい感じのレポートを作って」と言うと、日によってブレます。いい感じの日もあれば、見にくい日もある。プログラムで型にはめれば、このブレをなくせます。

進捗可視化ツールが、まさに「型にはめる」の実例です。キャプチャする前のHTML・CSSは、AIにゼロから作らせていません。HTML・CSSで型を作っておき、型の中の情報を「プログラムで書き換える」か「AIで書き換える」かの2パターンで埋めています。信号機の色の基準が毎回バラバラでは困るので、タスク管理ツールの情報をプログラムに処理させ、機械的に色が決まるようにしています。AIの判断が入らないので、何度やっても同じロジックで評価されます。AIに作らせるのは提案文だけで、それを型に流し込むため、必ず同じ場所に同じように収まります。

これは「AIに模範解答を渡して、その通りに作ってもらう」のとは別物です。模範解答方式では、AIは見本を見ながらゼロからすべてを作るため、どうしても出力がブレます。型方式は、型自体をそのまま使い、中身だけを流し込みます。だから型が必要なのです。

③ 余計な仕事を引き受ける

3つ目は、余計な仕事をコードに引き受けさせ、AIには難しいことに集中させることです。AIは賢いので、ついすべてをAIにやらせたくなります。しかし「これは本当にAIでなければできないのか、コードで自動で決められないか」と考えてみるべきです。

例を2つ挙げます。報告に今日の日付を入れたいとき、「今日の日付を入れて」と言えばAIはやってくれますが、たまに曜日や日にちを間違えます。プログラムなら絶対に間違えません。ならば日付はプログラムで入れる方がよいのです。売上の合計も同じです。AIは複雑な計算もできる一方で、単純な計算をミスすることがあります。100回中99回は正確でも、1回間違えるかもしれない計算を当てにするのは不安です。「ここを足し合わせて、この数字で割る」というロジックをプログラムにすれば、毎回同じ処理が走り、ブレることはありません。

これはアテンションの話でもあります。AIにいろいろなことをやらせると精度が落ちます。性能を限界まで引き出したいなら、「この仕事は本当にAIにしかできないことか」「1つのタスクに集中できているか」を考え抜く必要があります。特に繰り返し動かすツールでは徹底的に、です。

プログラムがAIをサポートする仕事は、①チェックする(バリデーション)、②型にはめる、③余計な仕事を引き受ける、の3つです。この3つでAIの出力は安定し、同じ品質の報告が届きます。プログラムが書けなくても大丈夫です。「プログラムにやらせた方がいい場面がある」と理解してさえいれば、AIに自分で聞けます。

3つのコツの振り返り

1. 完成形の絵から作る — 最終的にどんな報告が届けばいいのか、ゴールの見た目を先に決めます。それがAIへの正確な指示になります。
2. 専門家に磨かせる — 同じAIに自分の仕事をレビューさせても、一貫性を保とうとするため限界があります。サブエージェントで、頭がフレッシュなAIにレビューさせます。
3. ブレをコードで止める — AIの出力はブレますが、プログラムはブレません。チェックする・型にはめる・余計な仕事を引き受けるの3つで、AIには考えることだけに集中させます。

月次課題|面倒な報告を自動化するツールを作る

今月の課題は「面倒な報告を自動化するツールを作る」です。ワークで書き出した、自分が面倒だと感じている報告をなくします(他のテーマでも構いません)。この課題は教科書の練習問題ではありません。作ったものは明日から仕事で使え、毎日・毎週・毎月の面倒が1つ減る、武器作りです。こだわり出すといくらでもこだわれてしまうので、まず小さく作るところから始めます。

考えるときは、4つのパーツに当てはめます。AIに一気に作らせるのではなく、4つの解像度を上げることが先です。

• トリガー — 毎週決まった時間か。毎週月曜日か。時間以外でもよく、「お客様からメールが届いたときに自動で報告」なども可能です。トリガーをどこで動かすかも考える必要があります。
• ソース元 — スプレッドシートか、社内のデータベースか、メールの受信箱か、Gitのリポジトリか。複数のソースを組み合わせることもあります。そして、それらをどのように取得するのか。
• 処理 — 数字を集計するのか、グラフにするのか、文章で要約するのか。見やすいビジュアルにするために何をするのか。AIに分析させてコメントをつけることもできます。
• 届ける先 — チャットか、メールか。どのような仕組みで届けるのか。

権限の壁と4つの選択肢

届け先は、自分が仕事で最も使っているコミュニケーションツール(SlackやTeamsなど)が理想です。しかし多くの会社では、チャットへの自動投稿は権限管理されており、誰でも勝手に投稿できる実装はできません。コミネコのようにSlackへ投稿するツールには、Slack上でボット(自動で投稿・応答するプログラムのアカウント)を作る必要があります。ボット作成自体は、SlackのAPIキーがあればAIがすべて自動でやってくれるので、個人や権限の緩い環境なら簡単です。しかし、しっかり管理された会社ではそうはいきません(スクールのSlackも権限の関係で受講生のボット追加は不可とされました)。

普段使っている場所で動くのが理想なので、会社に掛け合える余地があるなら掛け合う価値はあります。それが難しい場合の選択肢は4つあります。

1. 公式LINEを作る — LINEは身近なツールです。公式LINEを作成すれば、自分専用の報告ツールを作れます。無料枠には制限があるので確認が必要ですが、個人で動かすには無料で十分なはずです。
2. 自分専用のSlackワークスペースを作る — スクールや会社のSlackではなく、個人でワークスペースを作れば権限の制約はありません。無料で作れます。
3. メールで送る — Resend(リセンド)のようなメール送信サービスを使えば、比較的簡単に作れます。普段メールをよく見る人に向いています。
4. パブリックリンクに上げる — 無料で使えるSurge.sh(サージ)などで公開する方法です。自動で送られてくる形ではなく、同じURLを見に行くと更新されている、という形を作れます。

実例 — LINEで動く朝活記録ツール

簡単な実例として、LINEで動く朝活の記録ツールが紹介されました。朝活仲間同士で活動を共有するツールで、メンバーが投稿すると自動で集計が行われます。これを4つのパーツで見ると、次のようになります。

Google Apps Scriptは、スプレッドシートの裏側で動く小さなプログラムを作るときなどに使われる仕組みで、トリガーも設定できます。注意したいのは、処理がLINE上で動いているわけではない点です。LINEは連携する窓口を用意してくれているだけです。公式LINEを開設したら、連携するサーバーを登録する必要があります。自分が設定した場所としかやり取りできない仕組みで、そうでなければ誰でも勝手に投稿できてしまい危険だからです。

詳細なやり方はAIに聞くのが一番です。ただしパッと聞くだけでは間違った答えが返ることもあるので、「Webで公式の情報ソースを調べてから教えて」と言うと精度が上がります。毎日使っているLINEに報告が届き、複数人のグループに投稿することもできます。

トリガーをどこで動かすか — 3つの選択肢

朝活ツールはトリガーも処理もGoogle Apps Scriptで動かしていましたが、トリガーの選択肢は他にもあります。

Cursor Automationsは受講生が持つCursorのチームプランで利用でき、非常に便利だと紹介されています。注意点は、手元のパソコンではなくCursorのサーバー上で動くことです。サーバーは勝手に自分の情報を取得できないので、たとえば自分のカレンダーを見るための鍵を、Cursorのサーバー上に設定しておく必要があります。設定の仕方はAIに聞けば教えてくれます。

なぜ手順書を渡さないのか

講師は「今回から課題が難しくなる」と正直に伝えたうえで、細かい手順をすべて渡さない理由を説明しています。受講生の仕事や環境はバラバラです。営業の人もマーケティングの人もいて、使うツールも報告の形式もすべて違います。全員に同じ手順を渡しても、ただの練習問題になってしまいます。

最高の学びは自分の武器を作ることです。AIという圧倒的なサポートがある時代は、本質を理解したら、AIに聞きながら手を動かして学ぶのが最も効率的です。何より、作り上げたツールは自分自身が使えるものになります。わからないことがあれば、画面のキャプチャを撮ってAIに送って聞けば大丈夫です。課題の詳細な説明は受講生ポータルに掲載されます。

AIに聞いてもどうしてもわからないときは、同じチームのメンバーに相談します。「ここにつまずいている」と言語化すること自体が自分の勉強になり、チームの勉強にもなります。AIがある時代でも、わからないことは必ず生まれるものです。

次回グループセッションまでにやること

次回のグループセッションまでに、報告ツールを完成させる必要はありません。やることは3つです。

1. (必須・最低ライン)完成イメージの絵を作る — どんなレポートが送られてくるとよいのか、その絵を作ります。できれば実際に送られるものと同じ形が理想です。HTMLで図解を作るのがおすすめです。画像生成で作る手もなくはありませんが、細かいチューニングが難しくなります。慌てて作らせるのではなく、自分が何をしたいのかをAIと対話しながら理解し、どんな見た目だと見やすいのかをCursorなどでイメージにしましょう。
2. 4つのパーツに分類して作り方を決める — トリガーはどこで動くのか。ソース元はどこで、どうやって取ってくるのか。どんな処理をどこで動かすのか。届け先はLINEかSlackかTeamsかメールかURLか。4つのパーツの解像度で説明できるようにします。
3. (可能であれば)3つのコツをどう生かしたかを説明できるようにする。

時間がなくなると、慌ててAIに丸投げして作り、収拾がつかなくなります。余裕を持って取り組むことが大切です。理想のものを作ろうとすると、わからないことがたくさん出てきます。それを1つずつ理解していくプロセスにこそ価値があり、一生使える教養になります。完成を急ぐより、作りたいものを決め、必要な知識を身につけることを優先します。動くものに仕上げるのは、グループセッション以降で大丈夫です。

最後に、学び方のアドバイスです。講義でわからなかったことは、24時間以内に解決することが推奨されています。それ以降になると忘れてしまうからです。

次の講義では、報告を自動化した、さらにその先の話へ進みます。

まとめ

• 図解Skillは便利だが、人間の指示がないと動かない。同じ手順の繰り返しは自動化する
• 仕事は認知→意思決定→実行の3ステップで進み、最もレバレッジが効くのは認知。報告の自動化は認知を早め、意思決定を変える
• 起きなかった問題には気づけないため、自動化の本当の効果(防げた事故・取り逃がさなかった売上)は見えにくいが、そちらの方がはるかに大きい
• 自動化ツールは必ず4つのパーツでできている。トリガー(きっかけ)・ソース元(データ)・処理する場所(加工)・届ける先(送付)
• 時刻トリガーはGitHub Actionsなどで設定できる。設定はYAMLファイルをリポジトリに置いてプッシュし、手元ではなくサーバー上で動く
• 他のサービスからデータを取るにはAPIキーという鍵が必要。クレジットカード番号並みに厳重に扱い、Gitには絶対にコミットしない
• コツ1: 完成形の絵から作る。Tailwind CSSを使い、2秒で伝わる、スマホファーストの画像にする
• コツ2: 専門家に磨かせる。セルフレビューは一貫性の罠で限界があるため、頭がフレッシュなサブエージェントにレビューだけをさせ、修正はさせない
• コツ3: ブレをコードで止める。チェック(バリデーション)・型にはめる・余計な仕事を引き受けるの3つで出力が安定する
• AIの限界を超えられる人とは、AIとコードの使い分けがわかっている人
• 月次課題は「面倒な報告を自動化するツールを作る」。まず完成イメージの絵を作り、4つのパーツで説明できるようにする。わからないことは24時間以内にAIに聞いて解決する

新出用語

• Git — 誰がいつどんな変更をしたかを記録できる、無料でオープンソースのファイル履歴管理ツール。
• リポジトリ — Gitで管理されるファイルの保管庫。プロジェクトの情報一式をまとめる場所。
• コミット — 「誰が何をやったか」を記録するGitの作業単位。
• ブランチ — ある時点のファイルから分岐して安全に並行作業するGitの機能。合流はマージと呼ぶ。
• プッシュ — 手元の変更をGitHubにアップロードすること。
• クローン — GitHub上のリポジトリを手元のパソコンにダウンロードすること。
• GitHub — Gitをチームで共有しやすくするWebサービス。Microsoft傘下。
• GitHub Actions — GitHubの自動実行の仕組み。「毎朝7時に動かす」などのトリガーを設定できる。
• YAML — 設定ファイルを書くための、世界的に使われるシンプルな書式。
• トリガー — ツールを動かすきっかけ。時刻・ボタン・ファイル更新・チャット発言などを指定する。
• API — 他のサービスから情報を取ってきたり操作したりするための、アプリ同士をつなぐ窓口。
• APIキー — APIを使うための鍵。流出すると勝手に使われるため、厳重に管理する。
• ボット — チャットツール上で自動的に投稿・応答するプログラムのアカウント。
• ワークフローツール — n8n・Zapier・Makeなど、複数のサービスをつないで自動処理を組めるサービス。
• Playwright — AIやプログラムが操作できるブラウザ。サーバー上でのキャプチャ取得に使う。Microsoft製で無料。
• Tailwind CSS — HTMLの見た目を整えるモダンなCSSフレームワーク。図解作成時にAIへ指定するとよい。
• サブエージェント — 本体のAIが部下として呼び出す別のAI。フレッシュな状態でレビューなどを任せられる。
• プランモード — Cursorなどにある、実装せずに計画だけを立てるモード。
• バリデーション — 出力や入力が正しい形式かを、プログラムで機械的に検査する仕組み。
• Google Apps Script — Googleの自動化の仕組み。スプレッドシートの裏側で動く小さなプログラムを作れる。
• Linear — 講師のチームが使っているタスク管理ツール。APIキーで進捗データを取得できる。
• Cursor Automations — Cursorへの指示を決まった時間に自動実行できる機能。Cursorのサーバー上で動く。