AIを動かす側になる——越えるべき3つの壁

AIとやり取りを続けていたら、急に的外れなことを言い出した。何度やり直しを指示しても、ずれた答えしか返ってこない。AIを使ったことがある人なら、誰もがこうした「AIの限界」を感じた経験を持っています。この講義は、その限界がなぜ生まれるのかを仕組みのレベルで解き明かします。

限界の根っこにあるのは、コンテキストウィンドウ・アテンション・オートリグレッションという3つの壁です。いずれもAIの仕組みそのものから来る物理的な制約であり、根性や気合いでは越えられません。しかし壁の正体が分かれば、越え方を設計できます。

先に学んだ行動指針「AI-Driven Rules」の前半5つに続き、ここでは残りの5つを扱います。後半5つはすべて、この3つの壁を越えていくための方法です。

AI-Driven Rules前半の復習(ルール1〜5)

本題に入る前に、先に学んだ前半5つのルールを振り返ります。AI-Driven Rulesとは、AIをただツールとして使うのではなく、AIを使ってツールを作れるようになる——「AIを動かす側」に回るための行動指針です。

ルール1|90点から100点の戦いに備えよ。 AIは一瞬で90点のものを作れますが、そこでぬか喜びしてはいけません。勝負はそこからであり、90点にたどり着く走り始めから勝負は決まっています。AIは既存のコードや文章が増えるほど精度が下がり、最後の10点にエネルギーの9割がかかります。しかしそこにこそプロの価値があります。多くの人はAIによる全自動を夢見ますが、それは間違いです。最後の10点を詰めるための道具作りにAIを使うべきです。受講生が毎日取り組むドリルでテクノロジーリテラシーを高めるのも、最後の10点の戦いにそれが必要だからです。

ルール2|理解できないものを作るな。 AIに丸投げで作ると、最後の詰めができなくなります。合わせ調味料で90点の中華料理は誰でも作れますが、100点にするには素材・調味料・調理技法の理解が必要です。なぜ動いているか分からないまま進めると敗北が確定します。また、作っている最中は「記憶のゴールデンタイム」です。作りたいものがあるのにうまくいかない——この瞬間が最も記憶が定着するため、逃してはいけません。理解せずに進むと、特にAIでコードを書く場合、必ず最後に詰まります。

ルール3|自分の武器を自分で作れ。 Word・Excel・PowerPointのような汎用ツールに自分の仕事を合わせるのではなく、自分の仕事に合った専用の武器を作ります。

ルール4|図解で認知コストを下げろ。 情報が爆発している時代、文章だけでは認知コストが高すぎます。便宜上「図解」と呼びますが、正確にはビジュアル解説ページを作ることを指します。AIによる図解はおすすめですが、少し時間がかかるという難点があります。そこで、図解よりさらに軽量なビジュアル表現として講師が勧めるのがアスキーアート(文字だけで作る図)です。AIとチャットする際に「アスキーアートで出して」と言うだけで、文章だけよりはるかに分かりやすく、HTMLで図解を作るより軽量な図が得られます。講師はUI(画面)を作るとき、まずアスキーアートでAIに案を出させています。

ルール5|議論する前にプロトタイプを作れ。 AIで作るコストは劇的に下がりました。ただし「一気に全部作れ」という意味ではなく、むしろ逆です。実際に触れる簡単なプロトタイプ(試作品)を作ってから議論する、ということです。

AIの限界を決める3つの壁

AIの問題としてよく知られているのはハルシネーション(AIがもっともらしい嘘をつく現象)です。しかし本当に重要なのは、なぜAIがもっともらしい嘘をついてしまうのか、なぜAIの答えがいまいちになってしまうのか、という「なぜ」の部分です。その根っこにあるのが、これから見ていく3つの壁です。

壁1|コンテキストウィンドウ——AIの作業机には広さの限界がある

1つ目の壁はコンテキストウィンドウです。まず、誰もが経験する症状から見てみます。

• 最初に「ですます調で書いて」と指示し、しばらくは守られていたのに、やり取りを続けるうちに急にタメ口になっている
• 「自分はこんな仕事をしている」という前提を伝えたのに、会話の後半では完全に無視される
• 参考資料としてファイルを10個渡したのに、最初の3つの内容がすっかり抜け落ちている

コンテキストウィンドウとは机です。仕事をするとき、書類を机に広げます。しかし机には広さの限界があり、書類を次々に置いていくと、古い書類が端から押し出されて落ちていきます。AIの記憶はこの机と全く同じです。

そもそも生成AIはどういう仕組みか

土台から押さえます。AIはあなたのことを覚えていません。昨日の会話も先週の指示も、一切記憶していません。記憶しているように見えるだけです。

ChatGPT・Claude・GeminiといったAIには、それぞれモデルと呼ばれる本体があります。モデルはある時点までの膨大な情報を学習し、そこで固まったものです。学習を打ち切る期限をカットオフと呼びます。AIに質問したら古い情報が返ってきた経験があるはずです。2026年の話をしているのに2025年の前提で答えてくる場合、2025年にカットオフされたモデルを使っているとそうなります。

私たちがAIを使うとき、実際に起きているのは「カットオフ済みのモデルに毎回テキストを送り、テキストが返ってくる」——構造としてはそれだけです。毎回ゼロからのスタートで、前の会話のこともあなたが誰かも知らない状態から始まります。

AIを使うたびに、私たちは毎回ゼロからメモを渡しています。この一度に渡せるメモの量の上限がコンテキストウィンドウです。

トークンという単位

コンテキストウィンドウはトークン(AIが文章を処理するときの最小単位)で測ります。簡単に言えば文章の量です。日本語ではおよそ1文字が1〜2トークンで、モデルによって変わります。AIのコンテキストウィンドウは拡大を続けており、100万トークンを超えるのが当たり前になってきました。100万トークンはざっくり文庫本5〜10冊分、20万トークンでも文庫本1〜2冊分に相当します。

かなり多いと感じるかもしれませんが、押さえるべきポイントがあります。私たちがAIに送っているのは、自分が書いた文章だけではありません。裏側で大量の情報が送られています。

1. システムプロンプト — AIの振る舞いを定義する裏側の指示書です。「あなたは親切なアシスタントです。日本語で答えてください」のような内容が、見えないところで毎回送られています。CursorのようなAIエディターでは、ユーザーが設定したルールや、作業中のフォルダ構成の情報も自動的に送られます。
2. ツール定義 — AIがファイルを読んだり、コードを実行したり、ブラウザを開いたりできるのは、「こういうツールが使えます」という説明書がモデルに毎回送られているからです。Cursorで文章修正を頼むときも、指示が右から左に流れているのではなく、使えるツールの定義が自動で添えられています。
3. 過去の会話履歴 — 正確には毎回送られているというより「保持されている」が正しい表現です。これはキャッシュ(送った情報を一時的に保持する仕組み)によるもので、AI自体が覚えているわけではありません。やり取りを重ねるほど履歴が増え、コンテキストウィンドウを圧迫します。
4. 思考トークン — 最近のAIは回答前に内部で考えるプロセスがあり、この思考にもトークンが使われます。

このように、気づかないうちにコンテキストウィンドウはどんどん消費されていきます。AIはコンテキストウィンドウを超えると頭が悪くなります。過去の履歴を自動で圧縮する仕組みもありますが、それでも情報は削られ、削られると性能が下がります。

コンテキストウィンドウの広さがAIの評価を変えた実例

講師の体感では、2025年の時点でクリエイティブな文章を書かせるならGoogleのGeminiが最も優秀でした。Claudeは短い文章なら優秀でしたが、当時コンテキストウィンドウが20万トークンだったため、多くの情報を渡して複雑なことをさせるとすぐに一杯になり、性能が下がってしまいました。

しかし2026年になり、ベータ版ながらClaudeはコンテキストウィンドウを100万トークンに拡大しました。机が広がったのです。講師の評価では、文章作成の品質でずっと1番だったGeminiをClaudeが上回り、現在はほぼClaudeしか使っていないとのことです。もっとも、この勢力図は来週には変わるかもしれません。重要なのはどのモデルが良いかではなく、コンテキストウィンドウの広さがそれほど重要だという点です。

さらに、実際に使えるコンテキストウィンドウは公称値より少なめです。100万トークンと言われていても、講師の体感では40万〜50万トークンあたりから性能が下がり始めます。同様の調査結果も存在します。

壁2|アテンション——注意力の合計は常に100%

2つ目の壁はアテンションです。典型的な失敗パターンから見てみます。

講義やプレゼンテーションの原稿をAIに作らせるとします。テーマ・トーン・構成をすべて指定して「この通りに作って」と頼みます。出力を見ると、何かが違う。表現がイメージと違う、流れがおかしい。そこで「こういう表現はNG」「こういう言い方はしないで」とダメ出しを重ねていきます。

ダメ出しを続けるとコンテキストウィンドウを圧迫することは、壁1で学んだ通りです。そのためAIを上手に使う人は、追加指示ではなくリドゥ(やり直し)をします。やり取りを続けるとAIの頭が悪くなることは確定しているので、究極的には「一発で良いものを出せる最初のプロンプトを磨こう」という発想になります。すると次に何が起きるか。「これはやらないで」というNGリストを、10個、20個、30個とどんどん書き足していくことになります。

そして、ある時点からAIは言うことを聞かなくなります。NGを30個書いたはずなのに、最初に書いたルールを平気で破ってくる。これがアテンションの壁です。

仕組み——注目度の奪い合い

AIは受け取ったすべての情報を見て、どこにどれだけ注目するかを計算しています。この仕組みがアテンション(注意力)です。

アテンションを計算するとき、AIは内部でソフトマックスという関数を使っています(この言葉自体は覚えなくて大丈夫です)。ソフトマックスの働きは、すべての注目度の合計を必ず100%にすることです。

例えば「ですます調で書いて」とだけお願いすれば、注目のほぼ全部が「ですます調で書く」に向けられ、完璧に指示を遂行できます。ところが、ですます調の他に30個の指示を詰め込むとどうなるか。ですます調に向けられるアテンションが物理的に減るのです。NGリストを増やしまくっても限界があるのは、このためです。

AIの性能は向上を続け、より多くの場所に注意を向けられるようになっています。それでも、最新のモデルでさえ多数の指示を出すとアテンションが分散し、指示を守らなくなることが明らかになっています。

アテンションの向き先には傾向もあります。スタンフォード大学の研究では、AIは長い文章の最初と最後には注目する一方、真ん中に書かれた情報を見落としやすいことが分かっています。

この壁は当分なくならない

「言ったことを全部守ってほしい。大手AI企業はこの問題を知らないのか」と思うかもしれません。もちろん知っています。Google・OpenAI・Anthropicをはじめ、世界中のAI企業がこの壁を越えようと、何千億円どころではない兆単位の投資をしています。

では、すべてにアテンションを向けられるAIは完成するのでしょうか。2025年、世界最高峰のAI学会では、アテンションの仕組みを効率化しようとすると今ある能力を犠牲にしなければならない——速さと賢さの両取りはできない——ということが数学的に示されました。もちろんブレイクスルーの可能性は誰にも否定できません。しかし今の現実は、使い手がアテンションの仕組みを理解して使いこなすしかないということです。

壁3|オートリグレッション——AIは後戻りできない

3つ目の壁はオートリグレッション(日本語で「自己回帰」)です。聞いたことがない人も多いはずですが、簡単に言えばAIの「書く力」の限界です。

AIに長い文章を書かせると、最近はかなり改善したものの、まだよく起きる現象があります。前半は論理的なのに、後半になると雑になり、前半と矛盾したことを言い始めるのです。これには構造的な理由があります。

仕組み——1語ずつの一方通行

AIにアドバイスを求めると「結論から言うとこうです」と分かりやすい形で返してきます。人間なら、その後の話まで決めてから話し始めます。しかしAIは違います。「結論はこれです」と言った時点では、その後どんな話をするか決めていないのです。

生成AIの根本の仕組みは、1語ずつ順番に組み立てる。しかも後戻りができないというものです。例えばAIが「私は今日の会議で提案をした」という文を出すときは、次のように進みます。

1. まず「私」と書く
2. 「私」を見て「は」を書く
3. 「私は」を見て「今日」を書く
4. 「私は今日」を見て「の」を書く

毎回、自分がこれまで書いた全部を振り返って次の1語を決めます。10語目を書くときは9語分、100語目なら99語分、1000語目なら999語分——振り返る量は1語ごとに増えていきます。この仕組みこそが生成AIを誕生させ革命を起こした一方で、決定的な弱点でもあります。

AIは前に書いた部分を後から直せません。基本原理は完全な一方通行です。日常で例えるなら、修正ペンなしでボールペンの長い手紙を書くようなものです。気合いを入れて書いた手書きの手紙は、最初の1行は綺麗でも、だんだん散らかっていきます。

一番怖いのは途中で間違えたときです。人間なら新しい紙に書き直せますが、AIにはそれができません。手紙の1ページ目で「来週の月曜日」と書くべきところを「火曜日」と書いてしまったら、消せません。2ページ目以降はすべて火曜日を前提に話が進み、3ページ目には「火曜日の会議の後で」という間違った文章が出てきます。間違いが間違いを呼ぶのです。AIのアウトプットは長くなればなるほど品質が低下します。それも指数関数的に、です。

「読む」と「書く」はコストが全く違う

ここで重要な事実があります。AIにとって、読むことと書くことはコストが全く違います。

AIは読むのが得意です。受け取ったテキストを一括で処理できます。人間は手紙を1枚ずつ読むしかありませんが、AIはもらった手紙を一気に読めるイメージです。

一方、書くときは、次の1語を決めるたびにAIの脳をフル回転させる必要があります。しかも振り返る量は1語ごとに増えるため、アウトプット量が10倍になると計算コストは100倍になります。実際、最新モデルの料金表を見ると、書く(アウトプット)は読む(インプット)の5〜8倍の値段がついています。AIにとって書くことは、それだけ重たい仕事なのです。

実践——長い出力は刻ませる

この品質低下は、普段のチャットのやり取りの中でも起きています。仕事の資料一式を「全部要約して」と頼むと、AIは3000語の長い要約を一気に書き、後半になるにつれて品質が落ちていきます。

代わりにこうします。

1. 1回目: 「まず最初の章だけ要約して」と頼む。AIは500語書く。短いので品質が高い
2. 2回目: 「次の章を要約して」と頼む。ここがポイントで、さっき書いた500語の要約はこのターンでは入力に変わる。読むのはAIの得意分野であり、AIは新しい出力をゼロから書き始められる
3. 3回目以降: 同じように章ごとに刻んでいくと、性能が維持できる

以上がコンテキストウィンドウ、アテンション、オートリグレッションの3つです。3つとも、AIの仕組みそのものから来る物理的な制約です。

Rule 6|AIが見る情報を整えろ

ここからは壁の越え方、AI-Driven Rules後半の5つです。まずルール6「AIが見る情報を整えろ」です。

少し前まで、AIをうまく使うにはプロンプト(AIに与える指示)をうまく書くこと——プロンプトエンジニアリングこそ重要だと言われていました。指示が重要でなくなったわけではありませんが、これから私たちがやるべきことを簡単に言えば、AIがのびのびと働ける環境を作ることです。

壁1で学んだ通り、AIの机の広さには限りがあります。壁2で学んだ通り、注意力のパイは一定です。ではAIに仕事をしてほしいとき、関連資料をどさっと渡して「あとよろしく」と言ったらどうなるか。コンテキストウィンドウは一杯になり、アテンションは分散します。

これは人間も同じです。仕事を振られたとき、いきなり50冊の分厚いファイルを机に置かれて「ここに資料あるから仕事やっといて」と言われたら、どこから見ればいいのか途方に暮れます。しかし、整理整頓された50冊のファイルと「この3つのファイルは絶対に見ておいて。あとは必要だったら見て」という指示があれば、圧倒的に仕事がしやすくなります。人間もAIも同じで、AIの能力を引き出すには情報整理が必要不可欠です。

プロンプトとコンテキストの違い

紛らわしい2つの概念を整理します。

• プロンプト — チャット欄に打つ文のことです。音声や画像を送るケースも含め、ユーザーからAIへの指示を指します。「この文章を要約して」「ですます調で書いて」などです
• コンテキスト — 狭い意味では、明確な指示以外にAIへ渡す情報、つまり仕事に必要な参考資料を指します。より広い意味では、AIに送る以前の「AIに渡す可能性があるファイル群」(文章や画像の資料)を指します

壁1で見た通り、AIには打った質問以外にもシステムプロンプト・ツール定義・会話履歴・思考トークンなど大量の情報が送られています。プロンプトとは、その膨大な情報の中の「ユーザーからAIへの指示」の部分です。さらに言えば、そもそもどの情報をAIに送るのかという判断も裏側でなされています。CursorのようなAIエディターでは、プロンプトが最も優先順位の高い情報として扱われつつ、AIが必要と判断したファイルも情報として送られます。

ただし原理原則に立ち返れば、生成AIがやっているのは「文章を送って文章を返す」だけです。AIが理解しやすいように、プロンプト・コンテキスト・システムプロンプトという区分けがされているにすぎません。

プロンプトエンジニアリングからコンテキストエンジニアリングへ

プロンプトの工夫は、言ってしまえばAIに渡す膨大なノートの最初の1ページを綺麗に書くようなものです。かつてはそれが重要視されましたが、時代が変わりました。AIのモデル自体が賢くなり、最初の1冊が多少雑でも意図を汲んでくれるようになったのです。プロンプトエンジニアリングの価値は相対的に小さくなり、講師自身、今は丁寧にプロンプトを書くことはしないと言います。

代わりに重視されるようになったのが、プロンプトだけでなく全体として「どんな情報をAIに与えるか」という視点です。2025年、カーパシーという人物がこの転換に名前をつけました。コンテキストエンジニアリングです。カーパシーはOpenAIの共同創業者であり、テスラのAI責任者も務めた、AI界で最も影響力のある人物の一人です。

カーパシーはこう例えました。

• LLMはCPU — CPUとはコンピューターの中で計算をする頭脳部分です。AIで言えばChatGPT・Claude・Geminiのモデルそのもの
• コンテキストウィンドウはRAM — RAMはメモリー、つまりコンピューターが今この瞬間データを広げている場所
• 私たちの仕事はOS — OSはWindowsやiOS・Androidのような、全体の段取り役。今何を考えるべきか、どの順番で処理するかを管理する存在

CPUに当たるモデルがいくら高性能でも、メモリーがいくら増えても、段取りがまずければコンピューターは動きません。パソコンの使い方が分からない子供に超高性能なパソコンを与えても価値が生まれないのと同じです。この段取りをする仕事がコンテキストエンジニアリングです。人間がOSとなって全体を指揮しなければ、AIの力は引き出せません。

最近ではこの考え方がさらに広く捉えられ、ハーネスエンジニアリングという言葉も使われますが、基本の考え方は同じです。環境を整えよう、データを整えよう、ということです。

SSoTの原則とGit——正しい情報の置き場所を1つにする

情報を整えるうえで知っておくべき概念がSSoT(Single Source of Truth=信頼できる唯一の情報源)の原則です。AIの3つの壁を突破したいなら「SSoT命」と講師は強調します。

SSoTの原則とは、簡単に言えば「一番正しい最新の間違いない情報はこのファイルに全部ある」という状態を作ることです。我が家のカレーのレシピはこのノートに書いてある。それを書き写したメモや参考にした資料は関係ない。正しいのはこのノートだ——という状態です。

SSoTが守れていない職場のあるある

SSoTが守れていない状況は身近にあふれています。

• あるプロジェクトの仕様書について、最初のバージョンはSlackの3ヶ月前のスレッドにあり、修正版はメールの添付ファイルで送られ、最新版はGoogleドキュメントに書かれている。最新版が送られた瞬間は「これが最新だ」と分かっても、3日後にはどれが最新か分からなくなる
• 「共有フォルダ1つに全部入れよう」と決めたのに、中を開くと「企画書V1」「企画書最終」「企画書最終修正」「企画書最終修正確定版」が並んでいて、作った本人にも分からない。「新しいフォルダ」という、いつが新しいのか分からないフォルダがあり、最近作られた「オールドフォルダ」まである

この状態で「企画書をもとに提案資料を作って」とAIに渡すとどうなるか。AIはまずどれが正しいかを判断することにコンテキストウィンドウを使い、アテンションを消費します。その分だけ能力が下がります。人間が丸投げできない仕事は、AIにも丸投げできないのです。

SSoTとは「ここを見れば正解」という場所が常に1つだけあることです。いろいろな場所に散らかっているのはもちろんダメ、最新がどれか分からないのもダメ、そして見落としがちですが、整理されているように見えても同じ情報が複数のファイルに書かれているのもダメです。

なお「1つのマークダウンファイル(見出しや箇条書きを書けるテキスト形式)に全部入れる」という意味ではありません。それでは1つのファイルが重くなりすぎます。分割しても構いません。ただし、ファイルAとファイルBに同じ内容が書かれていてはいけません。内容が変わったとき、両方を編集しなければならなくなるからです。

Git——AI時代の最強ツール

SSoTを実践するための、AI時代の最強ツールがGitです。

Gitは簡単に言うと履歴管理ツールです。受講生の毎日のドリルの最初にGitシリーズが置かれているのには、それだけの訳があります。Gitは、文章やコードのファイルに対して、誰がいつどんな変更をしたかをコミットという単位で記録していきます。ゲームのセーブポイントのようなもので、履歴はすべて残ります。GitHub(Gitの履歴をチームで共有できるサービス)を使えば、チームで文章やコードを共有することもできます。

エンジニアの世界でGitを使うのは当たり前ですが、もうエンジニアだけのものではありません。講師は大げさではなく「全ての人がGitを使うべきだ」と考えています。AIの3つの壁を越えて限界を引き出そうとするなら、コンテキスト——自分が管理している文章やプログラムコード——のGit管理は必須です。

理由は明快です。AIにどんどん仕事を頼むと、たくさんのファイルが一気に編集されることがあります。これは人間の認知を超えており、本来は全部細かく見るべきでも、完璧には見きれません。しかしGitで管理されていれば、AIがいつ何をしたかがすべて記録されます。まずい変更に気づいたときには、元に戻すこともできます。

Git管理の世界は「安心な世界」です。安心してファイルを消せる、安心して上書きできる。消える恐怖がないから「企画書最終修正確定版」が生まれなくなるのです。

Gitはややこしく、エンジニアでも完璧に理解しているわけではありません。慣れるまでは苦戦し、何が起きているか分からなくなることもあります。しかし今はAIの力を借りて、コマンドを暗記していなくてもAIに聞きながら使えます。1つ1つ自分が何をやっているかを丁寧に確認しながら使うことが上達のコツです。

実例として、この講座を運営するSurprise社では、全メンバーがGitを使っています。コードを書くためだけのツールではなく、情報を整理するためのツールとしてです。会社の基礎情報も、経営判断で決まった情報も、講義の台本や原稿も、アプリケーションのコードも、すべてGit管理されています。Git管理されていないものは1つもなく、すべてが整理整頓されているからこそ、すぐにAIの力を引き出せるのです。

余談として、Gitにも限界はあります。「何が変わったか」は記録できても「なぜそう変えたか」は残りません。コミットメッセージ(セーブ時のコメント)に全部書くのは現実的に難しいためです。この背景から、AIとの会話ごと変更履歴と紐付けて記録するEntireのような新しいツールも生まれています。AI時代にGitの重要性は高まり、さらにAI時代に合う形へ発展しようとしています。

Rule 7|skillを育て続けろ

ルール7は、この講義の本丸です。

AIを使うというのは「記憶をなくしてしまう天才」と働くようなものです。AIは誰でもアクセスできるコモディティ(ありふれた汎用品)になりつつあり、誰が使おうが「記憶をなくす」という性質は変わりません。イメージとしては、毎日、優秀だけれど初めましての新入社員がやってきて「何をしたらいいでしょうか」と待っている状態です。昨日した説明を今日もしなければならないのは面倒です。理想は、すべてを覚えている同じ人——なんなら、自分の仕事も好みも全部分かっているベテラン——に来てほしいはずです。

skillとは、AI業界の規格の名前です。skillの良さを一言で言えば、いつも使うAIをベテランにできることです。

「プロンプトの保存」と何が違うのか

賢い人はこう思うはずです。「それって、プロンプトを保存しておけばいいんじゃないの?」——これは重要な問いで、ここを理解するかどうかでAI活用に大きな差が生まれます。

たしかに、毎回ゼロからタイピングする代わりに、AIに毎回伝えたいことをファイルにまとめて渡す方法はあります。例えばCursorには「コマンド」という機能があり、.cursorフォルダの下のcommandsという場所にプロンプトをマークダウンファイルで保存しておけば、スラッシュ(/)を打って呼び出せます。お客様へのメール返信を考えるプロンプトを保存しておく、といった使い方です。Cursorではskillも同じようにスラッシュから呼び出せるため、一見同じで、実行したときの動き方もほぼ同じです。

では何が違うのか。超重要な前提を覚えてください。skillは人間のためではなく、AIのために作られています。何か仕事をこなすAIのことをエージェントと表現しますが、skillはエージェントのためにあるのです。

「呼び出して使う」やり方には致命的な問題があります。AIは全部忘れてしまうので、保存したいプロンプトはどんどん増えます。10個なら覚えられても、20個、50個と増えれば、どれが何をするプロンプトか分からなくなります。仕事はチームで行うので、チームでプロンプトを共有すれば100個に達することもあります。どれを使えばいいのか分からない——人間は知らないものは使えないのです。

この問題を根本から解決するために考え抜かれた仕組みがskillです。skillは、AIが自分で「自分は何ができるか」を認識できるようにする仕組みです。もちろん、人間が「これ使って」と渡して動かすこともできます。

実演——「美容室予約して」だけで動く

講師はイメージが湧きやすい例として、ClaudeのCowork(パソコン作業をしてくれるデスクトップツール)でのデモを見せました。講師には行きつけの美容室があり、以前は毎回予約サイトで予約していました。今は「美容室予約して」と言葉で言うだけです。コマンドは打っていません。それだけでCoworkはブラウザを開き、いつもの美容室のサイトで空きを確認し、講師のGoogleカレンダーも見て、最適な予約候補時間を提案してくれます。

なぜ何も説明していないのに動くのか。講師がskillを作って登録してあるからです。skillには美容室の予約サイトのリンクも、Googleカレンダーを見ることも全部書いてあります。AIは起動した時点で、自分に何ができるかをもう分かっているのです。skillはAI業界の規格なので、Cursorでも、Claudeでも、Coworkでも動きます。講師は美容室予約のコマンド名すら覚えていません。

skillの中身

skillの作り方は規格で決まっています。

• skill.md — 手順書に当たるファイルです。何をやってほしいかをここに書きます。skillの名前をつけたフォルダの中にskill.mdを置く——基本はそれだけです
• 参考資料 — skillのフォルダ内に参考資料のファイルを置けます。例えば行きつけの美容室の詳細情報は、別ファイルに分けて保存できます。skill.mdの中に「ここが参考資料」と書いておけば、AIが必要に応じて読んでくれます
• スクリプト — プログラムコードも置けます。例えば原稿を書くskillで「最後に必ず文字数を数えてほしい」場合、AIは文字数を数え間違えることがあるため、あらかじめAIに作らせた文字数カウントのプログラムを同じフォルダに置き、それを動かすようskill.mdに書いておきます。これで文字数カウントが確実になります。skillの中でプログラムを使うのは、基本的に「確実にやってほしいこと」があるときです

そしてskill.mdの一番上にはディスクリプション——このskillが何をできるかの一文要約——があります。ここがめちゃくちゃ重要です。AIを起動したときに最初に読まれるのは、このディスクリプションだけなのです。

skillを100個作ったとして、起動時に全skillの中身を読み込んだら、コンテキストウィンドウを圧迫しアテンションが分散します。だからディスクリプションだけを読む仕組みが素晴らしいのです。短い文章で「何ができるか」だけを把握した状態を作れます。講師が「美容室予約して」と言っただけで動いたのも、AIがディスクリプションを読んでいたからです。

skillは育て続けるもの

AIドリブンな人材になるために、skillを育てて自分のAIをベテランにします。講師が心がけているのは「同じ作業を3回繰り返したらskillにする」です。パーソナルジムに通い始めたら、1回目は手作業で予約、2回目に「また同じことをやっているな」と気づき、3回目に二度と言わなくていいようにskillにする、という要領です。

skillは一度作ったら終わりではありません。問題が起きたらskillを更新します。講師がよく使うのは、Cursorのチャットのフォーク(チャットを分岐する機能)です。本来の仕事は元のチャットで続けつつ、AIの仕事が微妙だったと感じたら、フォークで分岐した先でskillを改善します。講師は「skillを作るskill」も作っています。Claude Codeのようなツールには、公式のskill作成ツールが最初から入っていることもあります。

skillでもSSoT厳守

skillを作るときも、SSoTの原則を思い出す必要があります。

例えばWebサイトのデザインをしてくれるskillを作るとします。Webサイト制作では、ブランドカラーやフォントを定めたデザインガイドラインを作るのが一般的です。これを全部skill内に書いてしまうと重たくなります。skill.mdの中身は500行以下が推奨されています。デザインガイドラインは別ファイルに分けて参照させれば、他のskillからも呼び出せます。

ただし「絶対に書かないのが常に正解」とも言い切れません。参照先はあくまで参照先なので、優先順位は下がります。「絶対に読んで」とskill内に書くのも1つの手ですが、それでも参照は参照です。具体的な内容を書けばSSoT違反にはなるものの、AIは理解しやすくなるという事実もあります。その代わり人間の管理が非常に大変になります。考え方としては原則書かない。参照先はリンクを書くだけにしておくです。

これからの働き方は、AIに緻密な指示をすることではありません。コンテキストを整理し、skillという武器を揃えておいて、人間は雑に指示する。するとAIが勝手にskillを駆使していい感じに仕事をしてくれる——まさにベテラン社員です。

skillの先にある限界突破の技術

skill以外にも、AIの限界を突破する技術があります。この講義では名前の紹介にとどめますが、次のようなものです。

受講生が毎日取り組んでいる「本気AIドリル」は、skillはもちろん、フックやサブエージェントをフル活用して作られています。最後は人間もチェックし、人間が詰め切っていますが、これらを活用することで、人間の手作業では不可能な量のクイズを作ることができています。

Rule 8|抽象指示より模範解答を作れ

繰り返しの作業をAIにやってもらうとき、skillを作るのはもちろん正解です。ではskillを作るといっても、何から始めればいいのか。その答えがルール8「抽象指示より模範解答を作れ」です。AIのアウトプットの品質を高めるには、模範解答が決定的に重要だということです。

AIにメール文面を考えてもらうskillを作るとき、精度が上がりにくいやり方は、抽象的な指示を増やしていくことです。「お客様に対しては丁寧にやり取りして」「結論から分かりやすく簡潔に」「会社のことをよく理解して」「嘘は絶対に言わないで」「感動する対応を考えて」「勝手に内容を創作しないで」——なぜダメかはもう分かるはずです。壁2、アテンションに限界があるからです。

最も効果的なのは、理想のメールを1通渡して「これと同じトーンで書いて」と頼むことです。これで一発で品質が上がります。Claudeを作っているAnthropic社自身が、公式ドキュメントで「1つのフォーマット例は、複数の形容詞的な指示より効果が高い」とはっきり書いています。AIを作っている側がそう言っているのです。

講師自身の実験もあります。講師は長年、月額制の有料マガジンを配信しており、企画原稿作りをAIにサポートさせています。高品質な原稿を作るために、(1)過去の評価が高かった記事の具体例だけを渡す、(2)抽象的な指示と参考資料を渡す、(3)両方を渡す、の3パターンを比較しました。完全な点数化はできないため講師の肌感覚ですが、最も品質が低いのは抽象的な指示のみ。具体例を渡すと、細かいことを言わなくても品質がグッと上がる。両方渡した場合は、具体例のみと同じかちょっと良い程度——という結果でした。

模範解答がないときの4ステップ

AIに理想通りの仕事をしてほしいなら、必要なのは模範解答です。では模範解答がないときはどうするか。次の4ステップです。

1. 雑にAIにお願いする — 現時点で分かる情報を、音声入力でもいいのでバーッと話してやらせてみます。こうして雑に一度やらせてみるやり方をゼロショットと言います(一般には「例を与えずに頼む方法」を指す用語です)。一度雑に振ってみることで、どのくらいの品質ができるのかが分かります。考えるたたき案があると、自分がどうしたいかを言葉にしやすくなります。複数案(例えばメール文面3パターン)を出してもらうのも有効で、「こういう文章を作ってほしいんだ」と自分自身の要望が明確になります
2. たたき台をもとに模範解答を作る — ある程度まではAIでやっても構いませんが、講師のおすすめは手作業です。ルール1「90点から100点の戦いに備えよ」の通り、最後の詰めはAIとどれだけやり取りしてもなかなか完成せず、手作業の方が早いのです
3. 模範解答をAIに渡す — 「これと同じようにして」と渡せば、以降は高精度で量産してくれます
4. 模範解答を改善する — 1つの模範解答ですべてのケースを網羅できないときは、2つ、3つと増やすのもありです。ただし増やせばいいわけではなく、本当に必要かを考えます。AIに仕事をさせる中で「最初に渡した模範解答がいまいちだった」と気づくこともあります。模範解答はなるべく少なく、洗練させていきます

受講生に配布された図解ツールは、まさにこの方法で作られています。実際に渡している模範解答は「APIの仕組みを1ページに図解したもの」で、モデルアンサーHTMLとしてツールに組み込まれており、受講生も見ることができます。またこのツールの実体はskillで、.claudeフォルダの下に置かれています。.claudeの下にskillを置けば、CursorもClaude Codeも読んでくれるためです。

やってしまいがちなミスは、AIにすべてやってもらおうとして、自分の手を動かして模範解答を作ることから逃げてしまうことです。部分的な修正にAIを使うのはOKです。それを繰り返して模範解答のレベルを上げていきます。「どうやったら一発でいい感じのものができるか」にとらわれてはいけません。AIの品質を上げるのは模範解答だからです。

Rule 9|スピードを出すな、対話しろ

AIの仕事は速く、クオリティも高い。だから危険です。AIは世界中の平均的なデータを学習しており、「いい感じにする」能力がとてつもなく高いため、ぱっと見はよく見えます。使っている人間はつい勢いよく進めてしまいます。

特に気をつけるべきは、新しくプロジェクトを始めたときや、AIでガンガンとツールを作り始めたときです。どんどん形になって気分がいいのですが、確実に痛い目を見ます。ある程度形ができたときに気づくのです——「あれ、そもそもこれ、こういう方向で良かったんだっけ?」と。

AIはゼロから作るのは得意ですが、膨大なコードやドキュメントがある中で絶妙な微修正をするのは苦手です。これはAIに限らず、仕事全般に言えることです。映画の主役を誰にするか会議室で議論するのはコストが低い。しかし主役が決まって撮影が終わった後に「やっぱり主役を変えよう」となったら、莫大なコストがかかります。

AIで気持ちよく進めた先に起きるのは、「そもそももっとこうした方が良かった」という気づきによるやり直しです。それだけでなく、解決が難しいバグも発生しやすくなります。

講義では2つの進み方が対比されました。

最新のAIはプログラムを書かせてもほとんど問題なく書きますが、コードが積み重なると甘くありません。なぜかうまく動かない箇所が増え、そこで「そもそもなんで動いているか分からない」と気づきます。ルール2「理解できないものを作るな」の通りです。あらゆる可能性を自分の頭で理解し、何がベストか分かりながら進めているから、やり直しが起きないのです。

なお、プログラムを書くときはリファクタリング(コードを整理整頓する工程)が必要不可欠です。リファクタリングを丁寧にやりながら進めることで、最後までAIが高品質な仕事をし続けてくれます。

講師自身、焦って「やってやって」と進めて痛い目を見たことが何度もあると言います。結局のところ人間は、AIに指示を出す時点では自分が何をしたいのか分かっていません。ぼんやりとしていて、作っていくうちに「そもそも何がしたいんだっけ」「ベストは何だっけ」と、作ってしまった後に気づくのです。新築の家を建てた後に「もっとこうすれば良かった」となるのはよくある話です。家を建て始める前に、あらゆる可能性を網羅して「これしかない」という選択を積み重ねるべきです。

そのための方法はシンプルで、AIと対話することです。「一緒に考えて」と伝えるだけです。AIの出した案が良さそうに見えても、サブエージェント(役割を切り分けた別のAI)に「レビューして」と頼み、第三者的なAIに検証させるのもおすすめです。講師は必ずやっています。

自分が何をやりたいか分かったら、新しいチャットを立ち上げて、やりたいことを伝えればいいのです。ルール5の「プロトタイプを作れ」も関連します。プロトタイプを作るのは完成を目指すことではなく、簡単なモックアップ(見た目の試作品)を作ることも対話の一部です。

AIのアテンションには限界があります。後から「修正して、修正して」と長いチャットを続けている時点で、負けは確定しています。

Rule 10|1クリックを減らせ

最後のルール10は「1クリックを減らせ」です。これまで何度も「AIで自分の武器を作れ」と述べてきました。武器すなわちツールです。では便利なツールとは何でしょうか。

ツールというと、機能が揃っていれば完成と思いがちですが、違います。一番大事なのは画面——UI(ユーザーインターフェース)です。UIとは、画面の中のどこに文章を置き、どこにボタンを置くかという、使いやすい配置を考えることです。

デザインの素養は確かに役立ちます。書籍では「ノンデザイナーズ・デザインブック」があり、究極この1冊で十分です。ただし世界中のUIデザイナーが口を揃えるのは「自分で作って学んでいくしかない」ということです。優れたUIは試行錯誤でしか生まれません。

なぜUIが大事なのか。人間はワンクリック・ワンタップ多いだけで、そのツールを使わなくなるからです。使うのがおっくうになるのです。

実例——送信ボタンを3つに分けた話

Surprise社では動画を作っています。実際の撮影前に、どんな演出にするかを指定した資料をまとめ、そこにフィードバックをしていきます。「ここ修正して」「この表現変えたい」「できればこうしたい」——少なくとも数十コメント、多いときは100コメント以上つきます。コメントが増えると、どれが絶対に修正すべきもので、どれができればやってほしいものか、判断が難しくなります。

そこで同社は、コメントにMust(必須)/ Better(推奨)/ Want(希望)の文字を絵文字付きで入れるようにしました。全員が辞書登録してすぐ呼び出せるようにしましたが、それでも面倒で書き忘れが頻発しました。そこで次の一手として、コメントの送信ボタン自体を3種類にしたのです。送信ボタンは必ず押すものです。その押す瞬間にMust / Better / Wantのどれかを選ぶ仕組みにしました。

講師は大学時代のコンビニのアルバイト経験を引き合いに出します。コンビニのレジは、最後の確定ボタンが「お客様の性別と年齢層」を選ぶボタンになっていて、それを押すことで確定しレジが開きます。レジを打つだけでデータが収集される仕組みです。「確定ボタンはどうせ押すのだから、そこで選べたらいい」という発想と同じで、Must / Better / Wantの入力はとても簡単になりました。

優先度が必ずつくので、フィードバック後の修正も楽になります。Mustから優先して直せばいいからです。フィードバックは多くの人が何十回、何百回、何千回と積み重ねるものです。そこでワンクリックを減らすことは、ツールを使う人全員の生産性を高めることになります。

ボタンを増やすことではない

「ワンクリックを減らす」と聞くと、ボタンをたくさん並べて全部ワンクリックで使えるようにすればいい、という発想になるかもしれません。イメージは飛行機のコックピットです。ボタンが何百個もあり、確かに全部ワンクリックです。しかしパイロットは何千時間も訓練して覚えます。プロ向けツールにボタンが多いのは、人間が習熟することを前提に作られているからです。慣れれば速いが、慣れるのが難しいのです。

講師が伝えたいのはボタンを増やすことではなく、いらないステップを消すことです。UIをボタンだらけにするのは簡単ですが、そのツールに慣れた人は良くても、新しく入った人には何が何だか分かりません。習熟コストの高いツールになってしまいます。本当にプロ向けを目指すならその方向性もありですが、自分以外の人が使うことを想定するなら、ボタンやスイッチだらけにしてはいけません。

絶対的な正解はありません。AIと対話し、モックアップを作ってもらい、どうするのがベストかを1つ1つじっくり考えて決めていくことで、優れたツールは完成します。

10のAI-Driven Rulesと月次課題

これで10個すべてのAI-Driven Rulesが出揃いました。

1. 90点から100点の戦いに備えよ
2. 理解できないものを作るな
3. 自分の武器を自分で作れ
4. 図解で認知コストを下げろ
5. 議論する前にプロトタイプを作れ
6. AIが見る情報を整えろ
7. skillを育て続けろ
8. 抽象指示より模範解答を作れ
9. スピードを出すな、対話しろ
10. 1クリックを減らせ

今すべて覚えられなくても大丈夫です。以降の講義はより具体的な話になっていきますが、すべてこのAI-Driven Rulesが土台にあります。

月次課題(3つ)

この月の提出課題は次の3つです。

1. 自己紹介の図解 — チームセッションで作成した自己紹介図解を提出します
2. パーソナル図解作成skill — 自分の仕事で使える図解を作るためのskillを育て、そのskillを使って作った図解のURLを1つ提出します。詳細はポータルに記載されています
3. (任意)skillの工夫をまとめた図解 — パーソナル図解skillでどんな工夫をしたのか、それ自体を図解にしてURLを提出します。次の講義で数分以内の発表に使うものです。デザインの指定はありませんが、パーソナル図解skillと違うデザインの方が見分けがつきやすくなります。Mustではありませんが、できれば作ることが推奨されています

短い時間で「自分専用の図解skill」という武器を作る課題です。完璧な完成は難しくて当然です。skillは育てるものだからです。限られた時間でベストを尽くすことが求められています。

成長は指数関数を描く

最初の1ヶ月は環境に慣れる月です。Cursorの使い方が分からない、思ったようにできなかった——そういうこともあるはずです。うまくいかないときは、なぜうまくいかなかったかを学ぶチャンスです。

ルール9で述べた「最後に一気に勝つ(丁寧に対話しながら作ると最後に一気に完成する)」という話は、受講生自身の成長にもそのまま当てはまります。講師は何万人もの人に教育サービスを提供してきた経験から、確信していることがあると言います。人の成長は指数関数的に上がる。新しいことを学んだ直後は、全然うまくなった気がしません。ベテランから見ると新人はなかなか上達しないように見えます。しかしそこで終わらせずコツコツ積み重ねると、後半にググッと伸びます。この講座での成長も同じ曲線を描き、何も身につかないまま終わる人はいません。課題に取り組み、ドリルを解き、興味を持ったことがあればやってみる——主体的に何かを作ってみる以上の学びはありません。

まとめ

• AIの限界は3つの壁——コンテキストウィンドウ・アテンション・オートリグレッション——から生まれる。いずれもAIの仕組みに由来する物理的制約である
• AIは「すぐに記憶をなくす天才」。毎回ゼロから情報を渡しており、その上限がコンテキストウィンドウ。システムプロンプト・ツール定義・会話履歴・思考トークンが裏側で容量を消費する
• アテンション(注意力)の合計は常に100%。指示を増やすほど1つあたりの注目度は物理的に減る。指示は必要最小限が一番効く
• AIは1語ずつ後戻りせずに書く(オートリグレッション)ため、長い出力ほど品質が落ちる。書くコストは読むコストよりはるかに高く、長い仕事は短く刻んで書かせる
• プロンプトエンジニアリングの価値は相対的に下がり、AIに与える情報全体を設計するコンテキストエンジニアリングの時代になった。人間の役割はOS(段取り役)である
• 「ここを見れば正解」が常に1つだけある状態=SSoTを守る。重複した情報はAIの能力を確実に下げる。GitはSSoTを支えるAI時代の必須ツールである
• skillはAIをベテランにする仕組み。ディスクリプションだけが起動時に読まれるため、増えてもコンテキストを圧迫しない。同じ作業を3回繰り返したらskillにし、育て続ける
• AIの品質を上げるのは抽象指示ではなく模範解答。ゼロショット→手作業で模範解答作成→AIに渡す→洗練、の4ステップで作る
• AIは速いからこそ危険。「もう大丈夫だろう」で進めず、確信できるまでAIと対話する。対話こそが最高速度を生む
• ツールの価値はUIで決まる。ボタンを増やすのではなく、いらないステップを消す。ワンクリックへの執着が人生を変えるツールを生む

新出用語

• ハルシネーション — AIがもっともらしい嘘をつく現象。
• コンテキストウィンドウ — AIが一度に扱える情報量の上限。机の広さに例えられ、超えると性能が下がる。
• トークン — AIが文章を処理する最小単位。日本語ではおよそ1文字が1〜2トークン。
• カットオフ — AIモデルの学習データの締め切り時点。これ以降の情報をモデルは知らない。
• システムプロンプト — AIの振る舞いを定義する、ユーザーからは見えない裏側の指示書。
• ツール定義 — AIが使える道具(ファイル読み取り、コード実行など)の説明書。毎回モデルに送られる。
• キャッシュ — 送った情報を一時的に保持する仕組み。AIが「覚えている」ように見える理由だが、記憶ではない。
• アテンション — AIが入力のどこにどれだけ注目するかを計算する仕組み。注目度の合計は常に100%。
• オートリグレッション(自己回帰) — 1語ずつ順番に、後戻りせずに文章を組み立てる生成AIの根本の仕組み。
• プロンプト — ユーザーからAIへの指示。チャット欄に打つ文章のほか、音声や画像も含む。
• コンテキスト — 指示以外にAIへ渡す参考情報。広義には、AIに渡す可能性のあるファイル群全体。
• コンテキストエンジニアリング — AIに与える情報全体を設計・整理する仕事。プロンプトエンジニアリングの発展形。
• SSoT(Single Source of Truth) — 信頼できる唯一の情報源。正しい最新情報の置き場所を常に1つにする原則。
• マークダウンファイル — 見出しや箇条書きを記述できるテキスト形式のファイル。
• Git — 誰がいつどんな変更をしたかを記録する履歴管理ツール。
• コミット — Gitにおける変更記録の単位。ゲームのセーブポイントに相当する。
• GitHub — Gitの履歴をチームで共有できるサービス。
• skill — AIが「自分は何ができるか」を認識できるようにするAI業界の規格。skill.mdという手順書を核に、参考資料やスクリプトを同梱できる。
• ディスクリプション — skillの冒頭に書く一文要約。AI起動時にはここだけが読まれる。
• エージェント — 仕事をこなすAIのこと。
• ゼロショット — 例を与えず、雑に一発でAIに頼むやり方。
• サブエージェント — 役割を切り分けて仕事を任せる別のAI。第三者的なレビューにも使える。
• フック — AIが何かを実行するたびに自動で動く仕組み。
• リファクタリング — 動作を変えずにコードを整理整頓する工程。
• UI(ユーザーインターフェース) — 画面のどこに文章やボタンを置くかという、使いやすさの設計。
• モックアップ / プロトタイプ — 議論や検証のために作る、実際に触れる簡単な試作品。