第4回知っていれば作れる──選べる人になる

「AIで自分の武器をいくらでも作れる時代」と言われても、多くの人は「何を作ればいいかわからない」で足が止まります。この講義はまさにその壁を越えるための回です。テーマは「知っていれば作れる、選べる人になる」。作り方の前に「何を、なぜ作るのか」を考える思考プロセスを扱います。

講義は3つのパートで構成されています。1つ目はAnthropic社のブログから学ぶ「効果的なコンテキストエンジニアリング」。2つ目はこれまでの内容を振り返りながら、AIの使い方がもっと上手になる3つのポイント。3つ目が本題で、漠然としたアイデアを「実際に作れる企画」に変える4つのステップです。新しい知識を大量に足すのではなく、これまで伝えきれなかった考え方を伝えることが、この講義の半分を占めています。

題材となるのは、講師が実際に3時間で開発した「リアルタイム議事録ツール」です。会議中に決まったことがほぼリアルタイムでToDo(やるべきこと)として画面に現れる、このツールが生まれるまでの思考の道筋を追体験していきます。

テクノロジーの学び方──今が一番わからなくなるタイミング

この講座はAI・クリエイティブ・テクノロジーの3つのスキルを掛け合わせた人材を目指すもので、テクノロジーも本格的に扱います。ここで言うテクノロジーとは、主にソフトウェアエンジニアリング(ソフトウェアを設計・開発する技術)のことです。

ソフトウェアエンジニアリングの技術の幅は広く、たくさんの知識が互いにつながり、土台となる技術も存在します。そのすべてをいきなり理解するのは難しいものです。講師自身、10年以上ソフトウェアエンジニアリングと向き合ってなお、日々勉強不足を痛感すると述べています。学習の進度で言えば、いまがテクノロジー理解の観点で最もわからなくなるタイミングです。ここから1つずつわからないことを潰していけば大丈夫であり、焦る必要はありません。

一方で、今からテクノロジーを学ぶ人には大きな有利があります。AIを使えるからです。わからないことをAIに聞けば、人間に聞くよりわかりやすく教えてもらえます。講義中にわからないところがあればメモしておき、後で調べる進め方が推奨されています。

技術理解の土台は反復学習用のドリルです。講義の時間だけですべての技術を説明することはできず、技術の理解は「反復して慣れることで納得できるようになる」側面が大きいためです。ただし、それよりさらに効率がいい学び方があります。自分の仕事で使えるツールを実際に作りながら、必要なことを自分で調べて学んでいくことです。

AI活用の聖書──「そのトークンはコンテキストを消費するに値するのか」

講義の最初のワークは、Anthropic社(生成AI「Claude」の開発企業)の公式エンジニアリングブログ “Effective Context Engineering for AI Agents”(AIエージェントのための効果的なコンテキストエンジニアリング)を読むことでした。講師はこの記事を、これまでの講義3回分で伝えてきたことの中で「最も伝えたいこと」の答えが書かれた記事だと位置づけています。AIをより上手に使いたい人であれば必ず読むべき記事であり、「今の最新のAI活用のすべてはこの記事に収束される」とまで表現される、いわばAI活用の聖書です。

原文は英語で技術的な内容も含むため、AIをフル活用して読んで構いません。読み方の例は次のとおりです。

リンク先を開き、日本語に翻訳して読む
リンクをChatGPT・Claude・Gemini・Cursorなどに渡し、わかりやすくまとめてもらう
講師の定番プロンプトを使う──「入社したての新卒社会人でもわかるように、専門用語は解説しながら説明して」
時間があれば、AIの要約ではなく原文の翻訳や、原文に近い状態のものを読む

このブログの内容を講師なりに一言でまとめると、次の問いに尽きます。

トークン(AIが文章を処理するときの最小単位。文字や単語の断片)は、コンテキスト(AIに与える情報のまとまり)を消費します。AIに指示をするとき、情報は少なすぎず多すぎず──特に多すぎるのは良くない──本当に必要な情報だけを与えられているか。この問いに向き合い続けることが、現時点でのAI活用の本質だと講師は述べます。

重要なのは、これがHowTo(具体的な手順)ではなくビジョン、つまり迷ったときに何を考えるべきかという指針だということです。講師自身、最初にこの記事を読んだときは「そりゃそうだよね」と刺さらなかったそうです。しかしAIの力を引き出そうと試行錯誤するうちに「あのブログに書いていたことがすべてだった」と、今では完全に腹落ちしています。受講段階では「へえ、そうなんだ」という理解で構いません。大手生成AIを作るトップランナー企業が出した、AI活用のコツの公式文章を読んだというだけでも大きな前進です。自分でツールを作る中で、必ずこの問いに腹落ちする瞬間が来ます。以後のAI活用の話の裏には、常にこの問いが土台としてあることを覚えておいてください。

10のAI-Driven Rules──改めて強調したいこと

第1章で紹介された10のAI-Driven Rulesを、今だからこそ伝えられる補足とともに振り返ります。しつこいようですが、この講座で一番重要な考え方です。

90点から100点の戦いに備えよ — AIに指示するとパッといい感じのものができますが、油断してはいけません。そこからの詰めが大変です。できあがったものが膨れ上がるほどAIのコンテキストを圧迫し、性能が落ちていくからです。
理解できないものを作るな — 現時点で理解できないことが多いのは仕方ありません。あくまで原則として「なぜかわからないけど動いている」ものを作らないようにします。
自分の武器を自分で作れ — WordやPowerPointのような汎用ツールも良いものですが、今は自分の仕事に合わせた最適なツールを自分で作れる時代です。それができるかどうかが大きな差を生みます。ただし、ほとんどの人は「何を作ればいいかわからない」問題に突き当たります。この講義の後半はまさにその答え、つまり作るべき武器の考え方を扱います。3スキルのうち「クリエイティブ」に当たる部分です。
図解で認知コストを下げろ — 膨大な情報を脳に入れるにはビジュアルが重要です。第1章では受講生自身にも図解ツールを作ってもらいました。そして、作った図解ツールは「育てるもの」です。理想の新築の家を建てても時が経つと不満が出るように、ツールも作った瞬間から古くなります。便利であり続けるにはアップデートが欠かせません。
議論する前にプロトタイプを作れ — 欲しいものを実際に作って見えるようにすると、より良いアイデアが生まれ、人の心を動かせます。これまでは「まず見た目を作ろう」と強調してきましたが、「最適なプロトタイプ(試作品)とは何か」はこの講義の後半でより深掘りします。
AIが見る情報を整えろ — 最初のワークで読んだコンテキストエンジニアリングの記事と密接に関係するルールです。仕事で繰り返し使う情報はGit管理(変更履歴を記録する仕組みでの管理)がおすすめです。
スキルを育て続けろ — スキル(AIに仕事の手順や知識を教える定義ファイル)を制する者はAIを制すると言えるほど重要です。スキルという規格を作ったAnthropic社自身が「スキルはどう作り、どう考えればいいか」の公式ドキュメントを出しています。最初のワークと同様、自分で読み解くことが心の底から推奨されています。
抽象指示より模範解答を作れ — 抽象的な指示でうまくいくならそれで構いません。うまくいかないとき最もAIの性能を上げるのは「こういうのが欲しい」という模範解答です。文章でもWebサイトでも画像でも同じです。
スピードを出すな、対話しろ — AIは危険です。油断すると出力を盲信してしまいます。「いい感じにやってくれるだろう」とどんどんやらせると、どうしようもないガラクタができあがります。途中まで良くても修正のたびに壊れ、仕組みを理解していないと適切な指示ができず、すべてやり直しになります。
1クリックを減らせ — 自分のツールを作るときはUI(ユーザーインターフェース。操作画面)を作ることになります。使いやすいUIへのこだわりが重要です。ボタンをいたずらに増やせばいいわけではありません。UIデザインは専用のドリルで反復して学びます。

AIの3つの壁は独立していない

AIを活用するには、AIの限界を理解する必要があります。第1章で扱った「AIの3つの壁」──コンテキストウィンドウ(AIが一度に扱える情報量の上限)・アテンション(AIの注意力)・オートリグレッション(自己回帰。これまでの出力を見ながら次の1文字を予測し続ける仕組み)──は、それぞれ独立した概念ではなく相互に関係しています。

AIに渡す情報(コンテキスト)が多いと、AIの注意力(アテンション)が分散します。さらにAIは「これまでの自分の出力を見て次の1文字を考える」を続けているため、何も言わなくても一貫性を保とうとする力が常に働いています。だから「本当に合っている?」と聞くと「合っている」と答えやすいのです。

ではどうすればよいか。例えば、記憶をクリアにしたサブエージェント(本体とは別のコンテキストで動くもう1つのAI)を立ち上げてレビューしてもらう、あるいは別のAIを立ち上げる。つまりコンテキストウィンドウを分けるという対策が取れます。3つの概念がつながっていることを理解すると、対策も自然に導けるようになります。

報告自動化の4つのパーツと、自動化が変えるもの

本章の前のページで扱ったとおり、報告自動化ツールは4つのパーツで整理できます。レストランの例えとあわせて振り返ります。

パーツ	役割	レストランの例え
トリガー	自動処理の起点	料理を作り始める伝票・注文
ソース元(データの取得先)	どこから情報を持ってくるか	冷蔵庫
処理をする場所	AIやプログラムがどこで動くか	キッチン
届ける先	Slack・LINE・Teamsなどの出力先	お客様のテーブル

前のページで紹介された2つのツールでは、GitHubというサービスのGitHub Actions(決めた時間や条件で処理を自動実行する仕組み)でトリガーが設定されていました。トリガーを設定できるサービスはたくさんあり、何がしたいかによって最適な場所は変わりますが、「どこがトリガーになっているか」を押さえることが重要です。

処理をする場所については、注意点があります。例えば自分のパソコンで「毎朝7時に動く」トリガーを登録しても、実際に処理をするのは別のコンピューター、すなわちサーバーということもあり得ます。詳しい仕組みを今完璧に理解する必要はありませんが、自動でAIやプログラムが動くとき「それがどこで動いているのか」を理解した状態で作ることが求められます。

データの取得先も同様です。進捗可視化ツールで個人のタスク情報が必要なら、会社のタスク管理ツールからデータを持ってくる必要があります。クラウドサービスなら、データは個人のパソコンやスマートフォンではなく、そのサービスのサーバーの中のデータベースにあります。誰でも勝手には取れないため鍵が必要で、取ってくる仕組みをAPI(アプリ同士をつなぐ窓口)と言います。届ける先も同じで、見ず知らずの人が勝手にあなたのLINEに投稿することはできません。勝手には送れないから、鍵が要るのです。

報告をAIで自動化する意味は、作業を楽にするだけではありません。問題や新しい情報の認知が速くなり、意思決定が変わり、行動が変わります。講師の会社では、社内のSlackにAI関連ニュースが自動投稿される仕組みを作っています。これにより常に最新のAI動向を知り、便利なツールや機能をいち早く試せます。この仕組みがなければ、もっと便利なやり方があるのに古いやり方・古いツールを使い続けるという無駄が生まれます。なお、このAIニュースツールはSlack投稿前提ですが、基本的な考え方とプロンプトは応用できます。各自の環境に合わせたチューニング・セッティングは必要ですが、応用可能なものとして受講生に共有されています。

AI活用が上手になる3つの観点

ここからは、講義と課題に取り組んできた今だからこそ知っておきたい、AI活用上手になるための3つの観点です。

観点1|わからない時のAIへの聞き方

人によって理解しやすい方法は異なるため絶対的なやり方はない、という前提で、講師の推奨は次のとおりです。

1. スクリーンショット共有を効率化する。 わからないことをAIに聞くとき、最初にやるべき環境整備です。困っている情報をゼロから手打ちするより、画面をキャプチャして渡す方が速いからです。長い文章の場合、テキストより画像の方がトークンを消費しないという研究結果もあります。講師はトラックボールのボタンに「範囲指定キャプチャ+自動コピー」を割り当てており、これができないと生産性がかなり下がると述べています。

Windows: Windowsキー + Shift + S
Mac: 有料ですがCleanShotというアプリがおすすめ
iPhone: iOS標準の「ショートカット」アプリを設定すると、長押しだけで「キャプチャ+コピー済み」の状態にできる(設定手順は講義で紹介された「本気AI」の解説動画を参照)
Android: 機種により異なるため、同様の設定ができないかAIに聞いて調べる

2. 定番の解説プロンプトを持つ。 講師の定番は「入社したての新卒社会人でもわかるように、専門用語は解説しながら説明して」です。キャプチャ画像とこのフレーズ、記事のリンクとこのフレーズ、という組み合わせで大半のわからないことを解決しています。概念が複雑なときは「アスキーアート(文字で描く図)で直感的にわかるように図解して」と付けることもあります。

3. 使うAIは使い比べて決める。 講師は現在、パソコンでもスマートフォンでもClaudeアプリを使っていますが、以前はChatGPTの時期もGeminiの時期もありました。どれが使いやすいかは数週間単位で変わります。「どれが一番いいか」という発想より、同じことを聞いて自分で使い比べる方が確実です。

4. 自分の言葉で理解を確認する。 「こういう理解で合っていますか」「要するにこういうことですか」と自分の言葉で説明し、フィードバックをもらうことで腹落ちします。「理解できた」の基準は、まったく知識がない人にその概念を説明できるレベルになったかどうか。それを確認する手段が、自分の言葉でAIに聞き返すことです。

5. ウェブ検索が走っているかを確認する。 AIはモデルがリリースされた時点で学習を止めています。例えばChatGPTの新機能が今日リリースされても、ChatGPT自身に聞くと「知らない・存在しない」と返ってきます。最新かつ正しい情報が欲しいときは「ウェブ検索をして」と伝えるとよいです。言わなくても検索してくれることもありますが、言えば確実です。ウェブ検索を有効にするボタンも用意されています(有効にしていなくても、最新のAIは「検索して」「調べて」と言えば大体検索してくれます)。AIの処理プロセスの表示で、検索が実際に走ったかを確認できます。なお、普遍的な概念を聞くだけならウェブ検索は不要です。

観点2|仕事を楽にする──スキルとコンテキストを磨く

仕事を楽にするには「スキルを磨いてコンテキストを整理する」に尽きます。あるプロジェクトについてAIと壁打ち(相談相手として対話すること)を続けていると、やり取りが長くなるにつれAIは賢くなくなっていきます。そこで新しいチャット──より一般的には、新しいエージェント(自律的に仕事をするAI)を立ち上げる──必要が出ます。しかし新しいエージェントは基本的に記憶を失っています。最新のAIには情報を勝手にメモして次のエージェントに引き継ぐ機能もありますが、限界があります。新しいエージェントを立ち上げるたびに、プロジェクトの情報をゼロから全部渡すのは非効率です。だからこそ、コンテキストを整理し、スキルを磨き続けるのです。

具体例として、講師は「Inside Stories」という月額マガジンを配信しており、音声と記事を毎日1つ配信しています。最終的には講師自身が内容を理解して自分の言葉で話しますが、その前の叩き案となる原稿を作るスキルを、1年以上かけて磨いてきました。使い方は、Cursorでスラッシュ(/)からスキルを呼び出し、テーマを設定して投稿するだけです。すると、企画の骨子を作り、徹底的にリサーチを行い、結果をまとめ、それをもとに原稿の叩き案を作り、サブエージェントがレビューし、さらにブラッシュアップする──という流れが自動で進みます(実際はもっと複雑です)。

このスキルはいきなりできたのではなく、コツコツ磨かれてきました。スキルファイルの内容はもちろん、そこから読み込む先の資料も磨き続けています。磨くコツは、冒頭で学んだ「そのトークンはコンテキストを消費するに値するか」を考え続けることです。

なお、講義では確実に使うためにスラッシュから明示的に呼び出しましたが、スキルは本来、明示しなくてもエージェントが勝手に判断して使ってくれるものです。この仕組みの利点は、どんなスキルがあるかを全部覚えていなくても、やりたいことを言えば勝手に理想的な仕事をしてくれるようになることです。

このスキルの出力は、最初はあくまで参考程度でしたが、今ではそのまま読み上げてもほとんど問題ないレベルまで性能が向上しています。AI自体の性能向上もありますが、伝えたいことは「毎日磨き続けることで品質を上げられた」という事実です。コンテキストとスキルを磨き続けることで、仕事は楽になります。

観点3|最初から全部わかっているAIに育てる

最後は、スキルよりもっと上の階層の話です。例えばエンジニア的知識がない段階で開発をしていると、AIは「専門用語もわかるよね」という前提で返してきがちです。そのたびに「新入社員でもわかるように説明して」と毎回伝えるのは面倒です。スキルは特定の言葉ややりたいことに反応して自動で使われるものなので、「どんな時にもわかりやすく説明するスキル」というものは作れません。ここで使うのが「常に適用したいルール」の設定です。

例えばCursorにはCursor Rulesという仕組みがあり、「ユーザーのルール」と「プロジェクトのルール」があります。ユーザーのルールは、自分がCursorを使うときに常に適用されるルールです。「常に専門用語を避けて説明してほしい」と書いておけば、いつでも噛み砕いた説明になります。プロジェクトのルールは、そのGitリポジトリ(プロジェクトの保管庫)だけで適用したいルールを書く場所です。

この「プロジェクトごとの共通ルール」「自分がツールを使うときの共通ルール」という概念は、ツールをまたいで存在します。開発者向けツールClaude Codeでは、プロジェクト共通のルールはCLAUDE.mdというファイルに書く決まりで、同様にユーザーのルールもあります。ChatGPT・Gemini・Claudeのチャットサービスにも、常に適用したいルールを書く設定があります。講師はClaudeの設定に、自分のパソコンのスペックやオフィスの住所を書いています。技術の質問のたびに「Macを使っている」と言いたくないし、会社近くのランチを探すたびに住所を入力したくないからです。これらの設定も、スキルと同様に磨いていくものです。

重要なのは簡潔に書くことです。共通ルールには限界があり、AIから見た優先度も低いのです。例えばCursor Rulesに「テンションの高い喋り方をして」と書けばテンション高く返ってきますが、その状態でチャットに「仙人のような落ち着いた喋り方で話して」と言うと、チャットの指示が優先されます。実際にチャットに入力するプロンプトが最も優先順位が高い、とAIが評価する仕組みになっているのです。

正確に言うと、これはAI自体の仕組みではありません。生成AIは「文章を送ったら文章を返す」ことしかできず、優先順位という概念を持っていません。各サービスがシステムプロンプト(サービス側があらかじめAIに与えている指示文)で、そのように優先順位をつける設定をしている、というのがより正しい理解です。

デモ──3時間で作られたリアルタイム議事録ツール

ここからが後半の本題、「アイデアを作れる企画にするプロセス」です。まず、考える題材となるワークがあります。

このワークに取り組むと、わからないことだらけであることに気づきます。良いアイデアがわからない、どんな技術を使えばいいかわからない、そもそも同じことができるツールが世の中にあるかもわからない。この状況は、地図もコンパスもないのに無人島にたどり着いてしまったようなものです。講義では、この無人島を冒険するための地図とコンパスとなる4つのステップが示されます。

その前に、イメージが湧くように、このお題への解決策となるツールのデモが紹介されました。講師が作った「リアルタイム議事録ツール」です。

プロトタイプなので見た目はシンプル
録音を開始すると会話のログ(普通の文字起こし)が表示される
重要なのはもう1つの欄で、会議をしながら「決まったこと」が溜まっていく
ツールは30秒ごとに自動更新され、開始ボタンさえ押せば、ほぼリアルタイムで「ここまでで決まったToDo」がわかる

このツールは、ワークの3つの困りごとをすべて解決しています。誰がいつまでにやるかが可視化され、リアルタイムに表示されるタスクを見れば期限が決まっているか否かが一目でわかります。決まっていなければその場で決めれば、自動で更新されます。また、普通の議事録は会議が終わってから作るため「会議で決まって満足し、翌日何をやるんだっけと思い出せない」ことが起きますが、このツールならリアルタイムでタスクが出るので忘れられません。

本格的なサービスにするにはまだ改善の余地がありますが、土台はできています。そして開発にかけた時間は3時間です。

やることは4つです。

課題を分解する
自分が作る意味を見極める
MVPを定義する
POCで検証する

ステップ1|課題を分解する

「AIで自分の武器をいくらでも作れる時代です」と説明すると、多くの人が「何を作ればいいかわからない」と言います。また、先のワークで「既存のサービスでよくない?」と感じた人もいるはずです。もちろん、既存のサービスで問題が解決できるなら、莫大なお金をかけて作られた既存サービスと同じものをゼロから作る必要はまったくありません。すでにあるものをゼロから作るのは「車輪の再発明」(すでに確立された仕組みを知らずに作り直す無駄)です。武器・ツールを作ること自体が目的になってはいけません。わざわざ作る以上は、既存のサービスでは実現できないものであるべきです。では、どう見極めればいいのか。答えは「結論を出す前に、分解してみる」です。

作るべきツールのアイデアが浮かばないのは、物事を塊として見てしまっているからです。例えば「会議」を1つの塊として見ている。気づかないうちに「はい、会議ね」とラベルを貼り、深く物事を見なくなっているのです。無意識に脳で処理していることを意識し直すことを、アンラーニングと言います。

プロ野球選手の例えがわかりやすいでしょう。プロは打席でバットの持ち方や足の広げ方を頭で考えていません。言葉にしていては遅いので、飛んでくる球に集中しています。そこへ野球初心者が「どうやればいいんですか」と習いに来ると、プロは困ります。感覚でやっているからです。しかしプロも初心者の頃は「バットはこう持つ」「スタンスはこう構える」と頭で意識しながら反復練習し、気がついたら無意識にできるようになったのです。初心者に説明するには、自分が無意識でやっていることを意識して言語化し直さなければなりません。これがアンラーニングです。つまり、アンラーニングとは分解のことです。

「面倒な会議をなくせないか」と漠然と考えているときにやるべきは、この分解です。会議の予定調整から、決まったことを実行するまでのプロセスを言葉にしてみます。例えば──田中さんが会議をやろうと思いつく、カレンダーで自分の空き時間を見る、他の参加者の空き時間も見る、会議室の空きも見る、日程調整をする、会議室に入る、座る、パソコンを開く、画面に資料を映す、会議中に議事録を取る、終わったら議事録を元にタスクを登録する(実際は忙しくて翌日になる)──というように、とにかく細かく書き出します。

この分解のプロセスをAIにやってもらうのもおすすめです。例えばこう聞きます──「私が普段やっている会議の流れの解像度を上げたいので、最初から最後まで全部聞き出してほしい。質問は1つずつお願いします」。AIに聞き出してもらう利点は、勝手に省略できないことです。自分で書き出すとつい省略してしまいますが、AIはそもそものところから質問してきます。「会議で決まったことはどのように共有していますか」と聞かれて、「そういえば誰が何を言ったか後から思い出す作業を毎回やっているな」「曖昧な表現を後から具体化する作業をいつもやっているな」と、自分の中にあったのに見えていなかったものが、質問に答えるたびに1つずつ出てきます。

こうして対話しながら整理すると、漠然とした「会議が面倒」が9つの具体的な面倒に変わりました。

会議中に聞き取れなかったことを確認するのが面倒
誰がいつ何を言ったかを思い出すのが面倒
テキストに起こすのが面倒
要点を整理するのが面倒
タスクを抜き出すのが面倒
曖昧な表現を具体化するのが面倒(「なるはやで」を「4月15日まで」に、「検討します」を「来週月曜までに回答する」に変換する)
決定が覆ったときに修正するのが面倒(前回決まったことが次の会議でひっくり返る)
タスク管理ツールに登録するのが面倒
関係者に共有するのが面倒(会議に出ていない人にも決定を伝える)

本当はもっと分解でき、30個でも50個でも100個にでもなります。当たり前のようにやっている会議で、莫大な面倒を無意識にこなしていたことがわかります。この分解を最初にやらなければなりません。分解しなければ、いいアイデアは浮かばないからです。

分解すると、「既存のサービスがカバーできているのは何か」がより具体的になります。テキストに起こす・要点を整理するだけなら既存の議事録サービスでもできます。しかし他はどうでしょうか。聞き直す面倒はリアルタイムの話なので、後から文字起こしするツールでは解決しません。ToDoを抜き出す議事録ツールはありますが、精度が足りないこともあります。曖昧な表現の具体化については、既存の議事録サービスが勝手に納期を設定することはありません。素晴らしいAI議事録ツールはたくさんあるけれど、すべてを解決できているわけではない──ここで初めて、自分が作る可能性を検討できるようになります。

これは議事録に限った話ではありません。営業なら「お客さんに提案する」を塊で見ていますが、分解すればヒアリング・課題整理・社内の情報集め・資料作成・上司確認・修正・送付と分かれ、本当はもっと細かい面倒をクリアしていると気づきます。経理なら「月次の決算を締める」を塊で見ています。その分野に精通した専門家ほど省略するものです。だからAIに聞き出してもらうのが有効です。「私の〇〇の業務を最初から最後まで全部聞き出して」。何も言わないと一気に大量の質問をぶつけられるので、「1つずつ聞いて」と付けるのがコツです。

ステップ2|自分が作る意味を見極める

前提として、革命的なアイデアを確実に思いつけるプロセスは存在しません。分解はあくまで考えやすくするための方法論であり、「何を作っていいかわからない」人が最初にやるべきこととして紹介されています。分解からアイデアが固まったら──今回なら「リアルタイムにToDoが決まっていくツールがあればいいのでは」──次は、自分が作る意味があるのかを見極めます。同じことができるツールが世の中にあるなら、ゼロから作る必要はないからです。

ポイントは、類似サービスを調べるのは「分解した後」だということです。予備調査程度なら最初でも構いませんが、最初に本格的な調査をすると、世界には便利なサービスが大量にあるため、調査だけで膨大な時間を消費します。さらに、分解する前に類似サービスを眺めても、自分が何に困っているかがわかっていないので、既存サービスの良し悪しを見極められません。会議なら、会議を分解して解像度を高め、アイデアを出してから初めて「同じことができるものはあるか」と調べるべきです。

便利なAI議事録ツールはたくさんあります。その中で「リアルタイムにToDoを出してくれるツール」は、近いものはあっても「まさにこれが欲しかった」というものはありませんでした。ここで初めて、自分が作る意味が生まれます。類似サービス調査はAIに聞く形で構いませんが、注意があります。

そして、調べた結果「自分のアイデアを実現しているサービスはなかった。よかった、誰も思いついていなかったんだ」と考えるのは間違いです。アイデアは必ず誰かに思いつかれています。AI議事録の分野では、Googleのような巨大企業からスタートアップまで、覇権を取ろうと毎日考え抜いている人たちがいます。その中で誰も思いついていないことなどあり得ません。思いついてはいるが、何かしらのネックがあって実現できないか、優先順位が下がっている、と考えるべきです。

なぜ存在しないのかわからなければ、それもAIに聞けばいいのです。講師は実際に「なぜリアルタイムでToDoを出す機能は既存ツールにないのでしょうか」と聞き、2つのネックがあると教えられました。

ネック1: コストが高すぎる。 音声をリアルタイムで文字起こしし、ToDoを抽出するには、たくさんのAPIを叩く(呼び出す)必要があります。既存のAI活用サービスは、Googleのようなメガテック企業を除き、自社で生成AIを開発していません。裏では生成AIのAPIを使っており、費用がかかっています。その費用に利益を乗せて顧客に課金する必要があるため、お金のかかるAPI利用は顧客の料金内に収めたいと考えるのが当然です。

ネック2: プロダクトとしてのリスク。 ToDoが自動で出る機能を付けて、そのToDoが間違っていたらどうなるか。商用のプロダクトは品質を大事にします。1社の企業だけを満足させればいいのではなく、課金してくれるすべての顧客が「便利だ」と感じるレベルでなければなりません。会議がまだ終わっていない曖昧な段階でToDoを表示するのは間違える可能性が高く、プロダクトとしてリリースが難しいのです。

これはあくまで1つの見解ですが、講師は納得感があったと述べています。こうした事情から、既存のサービスでは実現できない機能はたくさんあります。そこにこそ、自分で作る意味があります。自分で作れば、他社サービスを使う場合のように利益を上乗せされることはなく、コストが下がります。商用サービスレベルの精度を出すのは難しくても、自分たちのプロジェクトや会社に最適化すればいいだけなら、ハードルはグッと下がります。

ステップ3|MVPを定義する

MVP(Minimum Viable Product。必要最小限の機能のプロダクト)は、スタートアップの世界では知らない人がいないほど基本の概念で、ソフトウェアに限らずハードウェアの開発でも使われます。何かを作り出す人は夢に溢れていて、「あれもできたらいい、これもできたらいい」と機能を詰め込んでしまいます。だからこそ、本当に必要な機能だけを見極め、それに価値があるかを検証しようというスタンスがMVP開発です。

言葉にするのは簡単ですが、実際にプロダクトを作り始めると、MVPを考えるのは非常に難しいと気づきます。講師は16年前に起業してWebサービスを作っていた頃からMVPを考えようと言い続けてきましたが、わかっているはずなのに気がつくと機能を詰め込んでしまうものだと言います。これはどんな人がやっても必ず起きます。無意識のうちに「あれもこれもできなきゃ」と認知が歪んでしまうからです。

MVPは仮説検証のために作ります。リアルタイム議事録ツールで検証したいのは、「会議をしながらリアルタイムにToDoが決まっていく体験」が実現できたとして、それを便利に感じるのか。社内ツールとして使うので、会社の他のメンバーも「これは便利だ、手放せない」と感じてくれるのか。その仮説を検証するための、本当に極限まで最小限の機能にするべきです。

MVPを考えるうえで理解しておくべきなのは、次の考え方です。

自分たちにとって便利な武器を作るのは、その武器に価値があるから意味があります。スコップが便利なのは、手で掘るより楽だと皆がわかっているからです。しかし自分たちが作るツールに価値があるかどうかは、あくまで仮定でしかありません。MVPを検証したいなら、まず「コードを書かずに同じような体験を作れないか」と考えます。

例えば「リアルタイムに議事録ができることに価値がある」という仮説を検証したいなら、会議にオンラインで社内メンバーを1人参加させ、そのメンバーは議論には加わらず、手打ちでいいのでリアルタイムに決まったことをまとめてもらう。これでリアルタイムAI議事録ツールと同じ体験ができます。人力でこの体験を試したとき、「これはすごく便利だ、面倒がなくなった」と感じるのか。ツールを作ろうとしていない他のメンバーも「これはいいね」「また使いたい」と言ってくれるのか。そう思えないのであれば、頑張ってコードを書いてツールを完成させても、解決すべき問題はなかった、もしくは解決策として適切ではなかったことになります。

プログラムや生成AIはあくまで道具です。MVP開発には課題仮説と解決仮説という2つの仮説があります。「会議で決まったことを後で思い出して共有するのが面倒なはずだ」が課題仮説、「会議中にリアルタイムにToDoが可視化されれば会議が楽になったと感じるはずだ」が解決仮説です。コードを書かないとこの2つを検証できないのか、真剣に考え抜かないと痛い目に遭います。講師自身、エンジニアとして起業しWebサービスやアプリを開発・リリースする中で、何度も痛い目に遭ってきたそうです。

絶対に使われるものを作る方法はありませんが、人力でもいいので課題仮説と解決仮説を検証することはできます。作りたいものによっては人力では無理で、小さくプロダクトを作ってみるしかない場合もあります。ここで伝えたいのは「本当に限界までコードを書かないことを考え抜いたのか」という観点です。私たちはつい、作ること自体を目的にしてしまいます。極力コードを書かずに仮説を検証し、「ある程度いけそうだ」となって初めて、実際に動くプロダクトを作ります。世の中的には、この段階で作るプロダクトをMVPと呼ぶイメージが強いです。

ただし、補足があります。「極力コードを書かない」はセオリーですが、AI時代になって簡単なプロトタイプを作るハードルはどんどん下がっています。リアルタイム議事録の人力検証のために人を集めて調整して説明する1時間があれば、慣れている人なら実際に動くものを作れてしまうこともあります。本質は「コードを書くのは大変だから低コストなやり方を選ぼう」ということであって、AI時代の今は人力の方がむしろ大変な場面も増えていくでしょう。どちらが速いかは、作る人の能力にも依存します。

では、実際に動くものを作るときの「ちょうどいい最低限」とはどのレベルか。基準は「こんな状態で恥ずかしい」と自分自身が感じることです。「やりたいことがだいたいできた」と思えてしまうなら、それはやりすぎです。リアルタイム議事録ツールなら、誰もがアクセスできるWebアプリケーションとして公開する必要はなく、自分のパソコンだけで動けば十分。表示もブラウザではなく、文章だけのマークダウンファイル(記号で見出しや箇条書きを表現できるテキストファイル)で十分。参加メンバーの自由登録機能も不要で、プログラムの設定ファイルに書けばいい。削って削って、みすぼらしいけれど仮説は検証できる、というMVPを定義します。

ステップ4|POCで検証する

POC(Proof of Concept。概念実証)とは、自分たちのやりたいことが既存の技術で本当にできるのかを検証することです。ツール開発でAIとやり取りしていると、こちらが何も言わなくてもPOCという言葉が使われることがあるので、意味を知っておく必要があります。POCもMVPと同じく、具体的な方法論ではなく考え方です。

MVPとPOCの違いは検証の観点です。MVPは「使う人が価値を感じるか」の検証、POCは「自分たちのやりたいことが技術的にできるか」の検証です。リアルタイム議事録ツールのMVPを作ると決めても、既存の技術で本当に作れるのかはわからない状態から始まります。既存の技術で作れないなら、それは実現できないアイデアだったということになります。

POCには2段階あります。

「ここまではできていないと困る」という最低ラインをクリアできるのかを実証する(これができないと始まらない)
その次の段階として、より精度・品質を高めたり、コストを下げたりできる技術は何かを比較検討し、実際に動かして実証する

まず、MVP(マークダウン形式で見出しや箇条書きが表示されるもの)が動くときの処理の流れを考えます。収録している音声データを文字起こしする必要がある──これは確定。文字起こしの中からToDoを抽出する必要がある──これも確定。文字起こしと抽出したToDoを、指定したマークダウンファイルに反映させる必要がある──マークダウンファイルの更新は必ずできるので、検証は不要です。

ここでやっているのは「POCが必要な部分を見極める」プロセスです。処理の流れを見渡して、考えなくてもいいものを除外していきます。文字起こし文章からのToDo抽出は、最新のAIならできます。ブラウザのChatGPT・Claude・Geminiに文字起こしを渡せばToDoを出してくれる──ということは、それらの生成AIサービスのAPIキー(APIを使うための鍵)を発行し、自分のツールからAPI経由でAIに処理させれば、同じことができるということです。よってここも除外します(どのAIが良いか、どんな指示が良いかという精度向上は2段階目のPOCの余地がありますが、最低ラインの検証としては不要です)。

残った課題は「パソコンのマイクで収録し、リアルタイムに音声をアップロードして、一定間隔で文字起こしをしていく」処理です。講師はこれに近い実装を過去にしたことがあるため、できるとわかっているものをさらに除外していきます。音声をAIで文字起こしすること自体は、ブラウザで音声を渡せばできるのでAPIでもできるはずです(正確には「できることがほとんど」です)。問題は「リアルタイムに」の部分です。

全体のフローはこうなります。収録開始ボタンを押し、音声を収録しながら一定の時間で区切って、文字起こしとToDo抽出を繰り返す。例えば30秒刻みなら、収録開始から30秒ごとに「最初からそこまでの音声すべて」もしくは「前回アップロードしたファイルとの差分」をAIに処理させます。部分的に送るのか常に全部を送るのかは設計判断です。迷ったらAIに聞けばいいのです。なお、常に最初から全部送るのは無駄が多いですが、MVPとしては十分です。無駄があってもシンプルな設計で構いません。

こうした場面で「そんなことができるのか、できないのか」を判断するところにテクノロジーのリテラシー(理解力・判断力)が求められます。ただし知識がなくても、処理の流れを考えれば「一定の時間間隔で収録した音声をアップロードし続けなければならない」というところまではたどり着けます。ここでAI-Driven Rulesが効いてきます。「スピードを出すな、対話しろ」──慌てて決めず、AIと対話する。「理解できないものを作るな」──すべてを理解できる必要はないが、「できるんだろうか」と疑問を持ったら、それは新しいことを学ぶチャンスです。

ここまでで焦りを感じている人のために念のため補足すると、この講義の目的はAI議事録ツールの技術的な仕組みを理解してもらうことではなく、アイデアを形にするまでのプロセスのイメージを掴んでもらうことです。技術的に理解できないところがあっても今は問題ありません。テクノロジーリテラシーが高い人でなければ、完全に腹落ちすることは難しいはずです。

わからないことは、そのままAIに聞きます。例えば「パソコンで音声を収録しながら、一定間隔で文字起こしをしていく仕組みを作るにはどうしたらいいのでしょうか。入社したての新卒社会人でもわかるように、専門用語は解説しながら教えて」。返ってきた答えで「なるほど、そんなやり方があるのか」と理解を深めます。さらに疑問が残ります。マイクの起動はどうすればいいのか。MacやWindows標準のボイスメモアプリは使えますが、それだと定期的なアップロードはできないはずです。できるかどうかわからないなら、これもAIに聞きます。すると「音声アプリを起動しなくても、プログラムからマイクをスタートできる」と学べます。それがわかったら、次は「会議が全部終わってからではなく、一定間隔で文字起こしするにはどうするか」を聞いていきます。

10年前なら、テクノロジーリテラシーがないと何をしていいかさっぱりわからず詰まっていました。今はリテラシーが高い方が速く正確にできるのは変わりませんが、知識がなくてもAIと対話しながら「どうやったら作れるのか」を自分で理解できます。これは革命的なことです。

処理の流れを洗い出したら、全体が動くことをPOCで検証します。プログラムからマイクを起動するのは本当に動くのか。一定間隔で文字起こしをするのは本当にできるのか。ここで検証の順序が重要です。

実際の検証もAIに伝えるだけです。「まだ文字起こしは行わず、一定間隔で音声が保存されることを確認したいです」。最初から文字起こしまでやろうとしないことがポイントです。一定間隔で会議の音声が保存されてさえいれば、あとはその音声ファイルをAPIで送信し、生成AIサービスのサーバーで処理されて文字起こしが返ってくる──これができるのは確定しています。一気にやろうとせず、「保存するだけ」をまずやる。AIにコードを書かせてみて、何をやっているかわからなければAIに聞き、自分の頭で理解します。自分で作りながらわからないことをわかるようにしていくのが、最も効率のいい学び方です。講師がどんなに上手に技術的な説明をしても、受講生が自分で疑問に思い、自分で調べて学ぶことに比べたら、話を聞いて学べることは10分の1に過ぎません。新しいスポーツを、人の話を聞くだけでできるようになる人がいないのと同じです。だからこの講座では、技術的な説明を講義内ですべて丁寧にやることはありません。学習効率が悪いからです。

音声が分割保存され、文字起こしが返ってくることがわかったら、次は文字起こしを保存し、そこからToDoを抽出する処理を作らせます。このように処理の流れ全体を見て、1つずつネックを解決していくこと、わからないことはAIに聞いて解決していけるというイメージが持てたなら、この講義のゴールとしては十分です。

最後に興味深い後日談があります。このツールをどう作ればいいかAIと壁打ちする中で、「Deepgram」というストリーミング(データを流しながら逐次処理する方式)の文字起こしに強いサービスがあることがわかりました。これを使えば、30秒ごとに生成AIへAPIを送らなくても、リアルタイムに文字起こしされていきます。「これができるならこっちの方がいい」と、実際のリアルタイム議事録ツールではDeepgramが採用されました。講師自身、Deepgramのことは知らなかったそうです。AIと対話する中で提案され、実際に動かしてみて良かったから採用した──皆さんのツール作りも同じプロセスになるはずです。最初から全部わかる人はいないのです。

以上が「アイデアを作れる企画にする4ステップ」です。課題を分解する、自分が作る意味を見極める、MVPを定義する、POCで検証する。報告ツールに限らず、すべてのツール開発・ソフトウェア開発で使える、アイデアを形にするプロセスです。

月次課題と、うまくいかなかったときの心構え

月次課題は、オリジナルの自動報告ツールの完成です。次の講義で、自分で作った報告ツールの発表会が行われます。MVPでいいので完成させることが目標です。報告ツールは簡単にも作れるし、こだわろうと思えばいくらでもこだわれてしまいます。どこまでこだわればいいか迷ったら、この講義の4ステップが指針になります。

どんなに頑張ってもうまく動かなかった、という人も出てくるでしょう。それは開発をやっていればよくあることで、それも含めて貴重な学びになります。何がうまくいかなかったのかを言語化し、仲間と共有することが推奨されています。

まとめ

AI活用の本質は「そのトークンはコンテキストを消費するに値するのか」という問いに向き合い続けること。HowToではなく、迷ったときの指針となるビジョンである
わからないことを聞くときは、スクリーンショット共有の効率化、「新卒社会人でもわかるように」プロンプト、自分の言葉での理解確認、ウェブ検索の確認が有効
スキルとコンテキストを磨き続けることで仕事は楽になる。講師の原稿作成スキルは1年以上磨かれ、そのまま使えるレベルに達した
Cursor RulesやCLAUDE.mdなどの「常に適用したいルール」で、最初から全部わかっているAIに育てられる。ただし優先度は低いので簡潔に書き、迷ったら書かない
作るべきツールが浮かばないのは物事を塊で見ているから。アンラーニング=分解で、無意識にやっている面倒を言語化する。AIに「1つずつ聞き出して」もらうと省略できない
類似サービスの調査は分解の後に行う。「誰も思いついていない」はあり得ず、「なぜ存在しないのか」を自分で説明できるようにする。既存サービスのネック(コスト・品質リスク)にこそ自分で作る意味がある
MVPは仮説検証のために極限まで削る。「コードを書いたら負け」を出発点に、課題仮説と解決仮説を人力ででも検証する。ただしAI時代はコードを書く方が低コストな場合もある
POCは「技術的にできるか」の検証。できるとわかっている部分を除外し、怪しいところから小さく検証する。全部を一気に作らない
ツール開発の最大の悲劇は、誰も使わないものを作ってしまうこと
自分で作りながらわからないことを調べて学ぶことが、講義を聞くだけの10倍の学習効率を生む

新出用語

コンテキストエンジニアリング — AIに与える情報(コンテキスト)を戦略的に選び、整えること。「そのトークンはコンテキストを消費するに値するか」という問いがその核心
エージェント — 自律的に判断しながら仕事をするAIのこと。新しいチャットを立ち上げることを「新しいエージェントを立ち上げる」と言う
システムプロンプト — サービス側があらかじめAIに与えている指示文。共通ルールとチャット指示の優先順位も、これによって設定されている
ハルシネーション — AIがもっともらしい嘘の情報を作ってしまう現象。調査をAIに任せるときは検索させ、情報ソースを出させることで対策する
アンラーニング — 無意識に脳で処理していることを、意識して言語化し直すこと。実体は「分解」であり、良いアイデアの源泉となる
車輪の再発明 — すでに世の中にあるものを、知らずにゼロから作り直してしまう無駄のこと
MVP(Minimum Viable Product) — 必要最小限の機能のプロダクト。仮説検証のために、極限まで機能を削って作る
POC(Proof of Concept) — 概念実証。やりたいことが既存の技術で本当にできるのかを、実際に動かして検証すること
課題仮説と解決仮説 — 「この面倒が存在するはずだ」という仮説と、「この解決策で楽になるはずだ」という仮説。MVPで検証する対象
ストリーミング — データを流しながら逐次処理する方式。Deepgramはストリーミングの文字起こしに強いサービス