生成AI解体新書　～AIによるゲーム開発の学びと記録～

「これからは、社員全員が生成AIを使ってください」

会社の中で、そんな号令を聞く機会が増えた。

資料作成、議事録の要約、メール文面の作成、調査、アイデア出し、プログラミング、データ分析、社内ナレッジの検索。たしかに、生成AIは便利だ。

これまで三十分かかっていた文章のたたき台が、数十秒で出てくる。ゼロから考えていた企画の論点が、瞬時に並ぶ。長い会議メモも要約できるし、複雑な情報も整理できる。自分一人では思いつかなかった視点が返ってくることもある。

初めて使ったとき、多くの人がこう思ったはずだ。これはすごい、仕事が変わる、自分の仕事のかなりの部分はAIに置き換わるのではないか、と。私自身もそうだった。

生成AIは、会社員にとって強力な道具である。それは間違いない。

しかし、会社の現場で使えば使うほど、私は少しずつ違和感を覚えるようになった。AI活用の号令は出た。でも、仕事は思ったほど減らなかったのだ。

メールの下書きは速くなった。議事録の要約も楽になった。調査の観点出しも早くなり、資料のたたき台も一瞬で出るようになった。それでも、会議は減らなかった。調整も減らなかった。承認も速くならなかった。上司への説明も、顧客への説明も、結局は人間が悩んだ。AIが作った資料を直す時間も、意外とかかった。

むしろ、別の種類の仕事が増えたようにも感じた。

AIが出した内容は本当に正しいのか。この表現を顧客に出してよいのか。この前提は社内事情に合っているのか。この数字はどこから来たのか。この資料は誰が責任を持つのか。この業務にAIを使ってよいのか。この出力を、そのまま後工程に渡してよいのか。生成AIは便利だが、便利だからといって仕事が自然に減るわけではなかった。むしろ別の仕事が増えているのではないか。

その違和感は、会社の中だけでは解けなかった。だから私は、会社の外で一つの実験を始めた。生成AIを使って、自分一人でゲームを作ってみようと思ったのだ。

学生時代、私は三国志のカードゲームを自作して遊んでいた。武将、武器、弓、盾、計略、薬。机の上にカードを並べ、友人たちと何度も対戦した。ルールは粗かったが、自分たちなりの熱量があった。

あのゲームを、今ならデジタルで復活させられるのではないか。生成AIがある。ChatGPT、Codex、Claudeがある。画像生成もあるし、仕様レビューもAIに頼める。文章化も実装支援もしてもらえる。長い間、頭の奥にしまっていた遊びを、AIソロプレナーとしてもう一度動かせる気がした。

結果から言えば、一発ではうまくいかなかった。何度も壊れた。ルールは揺れ、仕様は膨らみ、画面は出てもゲームとして破綻した。AIはコードを書いてくれたが、私はプログラミングに落とし込めるほどゲームのルールを厳格に設計できていなかったのだ。

その失敗を通じて、私は生成AIの仕組みを少しだけ解体して見るようになった。そして、生成AIを使う会社員に本当に必要なのは、プロンプト集ではなく、生成AIを運転するための基本構造の理解ではないかと思うようになった。

この記事は、その記録である。

生成AIの核心は、意外とシンプルである

生成AIを語ろうとすると、多くの専門用語が出てくる。LLM、プロンプト、コンテキスト、RAG、Transformer、AIエージェント、ファインチューニング、ベクトル検索、ガードレール、マルチモーダル。横文字が並ぶと、急に難しく感じてしまう。

しかし、会社員が生成AIを使ううえでまず押さえるべき核心は、意外とシンプルである。

LLMのインプットは、コンテキストである。そしてLLMは、そのコンテキストの次に来る確率が高いトークンを予測し続けている。

ユーザーが入力するプロンプトは、そのコンテキストの一部にすぎない。RAGで外部資料から取り出された情報も、コンテキストの一部である。会話履歴も、添付資料も、システム側の指示も、ツールの実行結果も、LLMに渡されるならすべてコンテキストに入る。

つまり、生成AIの基本構造はこうだ。コンテキストがあり、LLMがそれを読む。LLMは次に来るトークンを予測し、その予測を繰り返すことで文章やコードを生成していく。

この一点を理解すると、生成AIの見え方は変わる。

プロンプトは、AIへのお願い文ではない。LLMに渡されるコンテキストの一部であり、次のトークン予測を望ましい方向へ誘導する操作入力である。

RAGは、AIに知識を覚えさせる仕組みではない。外部資料や社内文書を検索し、必要な情報をコンテキストに差し込む仕組みである。

コンテキストは、LLMがその瞬間に見ている情報全体であり、LLMはその情報をもとに次のトークンを予測し続けている。

これが、私にとっての生成AI理解の出発点になった。

生成AIの解体図

私が考える、会社員がまず理解すべき生成AIの中核要素は四つある。
　①　LLM　　　　：　生成AIのエンジン
　②　コンテキスト：　LLMがその瞬間に見ている情報全体
　③　プロンプト　：　人間がコンテキストに投入する操作入力
　④　RAG　　　　：　外部資料や社内情報を検索し、コンテキストに差し込む仕組み

この中で一番ブラックボックスに見えるのはLLMなので、LLMだけはさらに三つに分けて見るとよい。
　①　Transformer　　　　　：　現在のLLMの中核となる基本構造
　②　パラメータ　　　　　  ：　モデルの規模を表すパラメータ数と、学習によって調整された重みの値群
　③コンテキストウィンドウ　：　LLMが一度に参照できる情報量の上限

である。

整理すると、次のようになる。

生成AIの解体図

• LLM

  • Transformer

  • パラメータ（パラメータ数／重みの値群）

  • コンテキストウィンドウ

• コンテキスト

• プロンプト

• RAG

車にたとえるなら、LLMはエンジン、Transformerはそのエンジンの基本構造、パラメータは学習によって刻まれたエンジン内部の調整値である。コンテキストウィンドウは運転中に見える視界の広さに近い。

コンテキストは、走行中に見えている道路状況にあたる。プロンプトは、ハンドルを切る、アクセルを踏む、ブレーキを踏む、その瞬間の操作入力だ。そしてRAGは、カーナビやセンサーのように外部情報を車へ渡す仕組みである。

この全体像を持つと、生成AIの使い方は変わる。プロンプトだけを工夫しても限界がある。LLMの性質を知らなければ出力を過信するし、コンテキストを整えなければAIは一般論を返す。RAGを使えなければ社内情報や最新情報に弱くなり、コンテキストウィンドウを知らなければ情報を入れすぎて大事な前提を埋もれさせてしまう。

私はこの構造を、三国志カードゲーム開発の失敗を通じて、ようやく実感することになった。

AIソロプレナーとして、三国志カードゲームを作ってみた

学生時代に作った、国志のカードゲームの概要はこうだ。勝利条件は、相手武将の全滅。武将には、武力、統率力、知力、人徳、体力があり、弓使い、水軍使い、将軍、軍師といった特性もある。そこに武器、弓、盾、計略、薬が絡む。剣・槍・斧は三すくみ、弓は距離と威力を持ち、盾は弓を防ぎ、計略は知力で扱い、薬は戦場で命をつなぐ。カードを並べるだけで、戦場が立ち上がる感覚があった。

当時は紙のカードで、手書きのカードもあった。友人とルールを足し、直し、また遊んだ。粗いゲームだったが、熱量はあった。

あれをデジタルで復活させたい、そう思った。

最初は、AIに企画を相談した。三国志カードゲームをブラウザで動かしたい。HTMLベースのWebアプリで作りたい。Unityではなく、まずはCodexで動くα版を作りたい。プレイヤーと敵軍が武将カードを出し、戦場で戦う。手札、山札、捨て札、体力、武器、アイテム、計略。カードゲームとして最低限の遊びを作りたい、そう伝えた。

AIはすぐに反応した。画面レイアウト案を出し、カードデータの構造を出し、ターン進行の流れやHTML・CSS・JavaScriptの雛形、さらにはゲーム名の案まで出してくれた。

最初に画面が出たとき、私はかなり興奮した。武将カードが並び、体力らしき数字があり、攻撃ボタンもある。戦場エリアも表示されている。学生時代に机の上で遊んでいたカードゲームが、ブラウザの画面に戻ってきたのだ。

その瞬間だけは、生成AIが魔法に見えた。プログラマーを雇わなくてもいい、デザイナーがいなくてもいい、企画から仕様、実装、レビュー、改善まで、AIと一緒に進めればよい、そう思った。

しかし、すぐに壁にぶつかった。

画面は出た。カードも並んだ。でも、ゲームになっていなかったのだ。

攻撃はできる。体力も減る。勝敗も出る。しかし、遊んでみると面白くない。勝敗は出るが、途中に駆け引きがない。カードゲームなのに読む余地が少なく、三国志なのに武将の個性が薄い。戦場に部隊を出しているのに、戦局が生まれないのだ。

私はそこで初めて気づいた。ゲームは、画面にカードが並べば成立するわけではない。コードが動けば、ゲームになるわけでもない。

カードゲームにはルールがいる。ルールには状態管理がいる。状態管理には画面との同期がいる。画面には、プレイヤーが判断できる情報量がいる。判断には、迷いと納得がいる。それらがそろわないと、ゲームはただの操作画面になってしまう。

でも、一発ではうまくいかなかった

最初に詰まったのは、ルール定義だった。

紙のカードゲームでは、曖昧な部分を人間同士が補っていた。「このカードはこの場面なら使える」「この武将は今回は戦場に出ている扱いにする」「弓の射程はここまで」「この計略は、今の流れなら効く」。そこは話し合って決めればよかった。学生時代は、それで遊べたのだ。

しかし、デジタルゲームは曖昧さを許さない。武将は手札にいるのか、戦場にいるのか、待機エリアにいるのか。疲労しているのか、死亡しているのか。前線なのか後衛なのか。弓の射程内なのか、計略の対象になれるのか。盾はどのタイミングで発動し、武器はいつ装備するのか。カードを使った後、どこへ行くのか。すべて決めなければならない。

AIに「三国志カードゲームを作って」と頼むと、それらしいコードは返ってくる。でも、私がルールを決めていない部分まで、AIは勝手に埋めてしまう。勝手に攻撃でき、勝手にカードを消費し、勝手に勝敗判定を入れ、勝手にUIを変え、勝手にカード効果を単純化する。それは一見親切に見えたが、私が作りたいゲームから少しずつズレていった。

次に詰まったのは、戦闘設計だった。

最初は、一対一の単純な武将戦に近かった。武力を比べ、体力を削る。分かりやすいが、三国志カードゲームとしては物足りない。そこで、三ライン同時戦闘の案を考えた。前線が複数あり、各ラインで武将がぶつかる。どこに強い武将を置くか、どこを捨てるか、弓でどこを狙うか、盾でどの攻撃を防ぐか、計略でどのラインを崩すか、これなら戦場が生まれる。

だが、今度は実装が一気に難しくなった。一ラインなら攻撃側と防御側を一組で処理できるが、三ラインになると同時解決が必要になる。どのラインから処理するのか。相打ちはありか。弓は部隊戦前に飛ぶのか、戦闘中に飛ぶのか。計略はメインフェーズで使うのか、部隊戦に割り込むのか。

画面表示も難しくなった。プレイヤーの三ライン、敵軍の三ライン、手札、山札、捨て札、武将詳細、弓・盾・計略・薬、使用済みカード、ログ、現在フェーズ、行動可能なカード。情報を増やすほど、ゲームは見えにくくなっていった。

私は何度も仕様を変えた。シンプルにしたいが、駆け引きは残したい。麻雀のように、相手の見えている情報と見えていない情報から読む楽しさを入れたい。でも、初見で覚えられないルールにはしたくない。その両立が難しかった。

弓と計略にも悩んだ。弓は、狙撃側が射程範囲内から対象を選ぶ、という点では分かりやすい。だが、強すぎると部隊戦の意味が薄れ、弱すぎると使われない。

計略はもっと難しかった。計略を使う軍師を指定し、計略カードを裏面のまま提示する。受け手側は、軍師の知力と露出している情報から仕掛けられた計略を読み、戦場の中から受け手武将を選ぶ。この構造にすれば読み合いが生まれる。だが、実装とUIは重くなる。裏面で提示するカードを画面上でどう表すのか。受け手は何を見て判断するのか。計略に必要な知力はどのルールで判定するのか。敵AIはどの程度読ませるのか。使われた計略カードはどこで確認できるのか。

私はAIに質問を重ねた。AIは毎回、それらしい案を返してくれる。しかし、案が増えるほど仕様は膨らんでいった。弓、盾、計略、武器、薬、武将特性、三ライン、同時戦闘、カード使用履歴、手札管理、敵AI、ローグライト化、英語対応、Steam展開。頭の中では夢が広がる一方で、実装画面ではバグが増えていった。

攻撃ボタンが反応しない。カードを使うと別のカードが消える。戦闘後に疲労状態が残らない。死亡した武将が次のターンに戻ってくる。敵軍の手札が見えてしまう。ログが正しく出ない。リスタートすると前回の状態が混じる。レイアウト修正でカード枠が崩れる。

AIにエラー内容を伝える。AIが修正案を出す。修正を入れる。一つ直ると、別の箇所が壊れる。この繰り返しだった。

そのうち、私は気づいた。AIが悪いのではない。私が全体の設計図を持っていなかったのだ。

どのカードデータが何を持つのか。武将の状態をどこで管理するのか。場、手札、山札、捨て札をどう分けるのか。フェーズ遷移をどう扱うのか。三ライン戦闘をどの順番で解決するのか。弓・盾・計略の処理順をどう定義するのか。UI更新をどのタイミングで走らせるのか。ゲームログをどこまで残すのか。敵AIの判断をどこまで単純化するのか。

こうした設計を曖昧にしたまま、私はAIに修正を頼み続けていた。AIは毎回、筋が通った修正を返す。しかし、全体設計が曖昧なままでは、修正が積み重なるほどコードは複雑になり、かえって壊れやすくなっていった。

これは、会社の仕事とまったく同じだった。目的が曖昧な資料。前提が共有されていない会議。責任分界が曖昧な業務改善。後工程を考えていない効率化。全体設計なしに進むシステム導入。AIを使えば、一つひとつの作業は速くなる。しかし、設計がなければ、速く壊れるだけなのだ。

三国志カードゲームで分かった、コンテキストの威力

三国志カードゲーム開発で一番痛感したのは、コンテキストの威力だった。

最初の私は、AIに短く頼んでいた。「カードゲームを作って」「弓カードを追加して」「計略を入れて」「三ライン戦闘にして」「バグを直して」。これでは、AIは一般論しか返せない。

三国志カードゲームの勝利条件、武将パラメータ、カード種別、三ライン構造、フェーズ設計、弓の射程、盾の防御条件、計略の読み合い、使われた戦術カードの確認仕様、初回実装で入れる機能と後回しにする機能。これらを渡さずにAIへ頼んでも、AIは私の頭の中を読めない。

そこで、私は仕様を文章に落とし始めた。まず勝利条件を書く。カード種別を書く。画面レイアウトを書く。ターン進行を書く。フェーズごとの操作を書く。初版で入れる機能と後回しにする機能を分ける。曖昧な点をAIに質問させ、矛盾点をレビューさせ、Codexに渡す前提を整える。

これを始めてから、AIの出力は変わった。AIが急に賢くなったのではない。AIに見えている景色が変わったのである。コンテキストが薄いと、AIは一般的なカードゲームを作る。コンテキストを厚くすると、AIは私の三国志カードゲームに近づいていった。

ここで、生成AIの仕組みが腹に落ちた。LLMは、私の夢を読んでいるわけではない。私が渡したコンテキストを読み、その次に続く出力を予測しているだけなのだ。

つまり、AI活用の品質は、プロンプトの文才だけで決まらない。AIに何を見せるかで決まる。

会社の仕事でも同じである。「DX提案書を作って」と頼めば一般論が出る。しかし「当社の現状、顧客の制約、意思決定者、過去の失敗、今回の予算、現場抵抗、導入後の業務変化」を渡せば、出力は実務に近づく。

AIの回答が浅いのは、AIが弱いからとは限らない。AIに見えている景色が浅いだけの場合がある。三国志カードゲームは、その事実をかなり痛い形で教えてくれた。

生成AIは、まだマニュアル車に近い

この経験を通じて、先ほどの例えに挙げたように、私は生成AIを車に近いものとして考えるようになった。ただし、今の生成AIは、完成されたオートマ車ではない。まして自動運転車でもない。むしろ、まだマニュアル車に近い。

見た目は簡単に見える。チャット欄に入力すれば、すぐに返事が返ってくる。専門知識がなくても使えるように見える。

しかし、実際に使い込むと、クラッチ操作が必要になる。ギアチェンジが必要になる。坂道発進で失敗する。アクセルを踏んでいるつもりでも前に進まない。急にエンストする。

生成AIも同じだ。プロンプトを入れれば、とりあえず出力は返ってくる。だが、前提が薄いと一般論になる。文脈がズレると出力もズレる。参照情報がなければ、もっともらしい間違いをする。一つのAIに全部任せると、途中で破綻する。レビューなしに進めると、後工程で事故が起きる。

三国志カードゲーム開発では、何度もエンストした。ルールを決めないまま実装へ進んでエンストし、UIを詰めないままカード種類を増やしてエンストし、状態管理を定めないまま三ライン戦闘へ進んでエンストした。AIに長い仕様を丸ごと投げて要点が埋もれ、Codexに依頼する前提を整えず、修正のたびに別の機能が壊れてエンストした。

最初は、AIの性能不足のせいにしていた。しかし、違った。私が運転できていなかったのだ。

クラッチにあたるのは、文脈のつなぎ方である。ギアにあたるのは、タスク分解である。ハンドルにあたるのは、プロンプトである。視界にあたるのは、コンテキストである。ナビにあたるのは、RAGや添付仕様である。ブレーキにあたるのは、レビューと人間の判断である。

この運転感覚がないままAIを使うと、速く進んでいるように見えて、どこかで必ず詰まる。

車の運転者は、仕組みを最低限知っている

車を運転する人は、整備士ではない。エンジンを分解できなくてもいい。クラッチを修理できなくてもいい。ブレーキを設計できなくてもいい。トランスミッションの仕組みを専門家レベルで語れなくてもいい。

しかし、マニュアル車を運転するには、単にアクセルとブレーキを知っているだけでは足りない。クラッチを踏み、ギアを入れ、半クラッチでつなぎ、エンジンの回転数を感じ、坂道で下がらないように発進する。ギアが合っていなければ加速せず、クラッチ操作を誤ればエンストする。これは自動車工学を学ぶ話ではなく、車を安全に動かすための、運転者としての基本である。

生成AIも同じである。Transformerを開発できる必要はない。LLMを自分で学習させる必要もない。GPUクラスタを設計する必要もない。

しかし、LLMが何をしているのか。コンテキストがなぜ効くのか。プロンプトがなぜ単なるお願い文ではないのか。RAGが社内情報活用でどんな役割を持つのか。この程度は、業務で生成AIを使う人間が知っておいた方がよい。それはAIエンジニアの知識ではなく、AI時代の会社員に必要な、運転者の知識である。

私はこの知識を、「生成AIの免許証」と呼びたい。

ただし、ここで使う免許証は、資格ビジネスではない。AIエンジニアになるための専門資格でもない。難しい数式を覚える話でも、論文を読み込む話でも、GPUの設計を理解する話でもない。

車を運転する人が整備士でなくてもよいように、生成AIを使う会社員がAIエンジニアである必要はない。しかし、車を運転する人が最低限の仕組みを知っているように、生成AIを業務で使う人も、最低限の仕組みを知っておいた方がよい。それが、私の考える「生成AIの免許証」である。

AIチームを組んで、ようやく前に進み始めた

「生成AIの免許証」を取得に必要な最低限の知識は、LLM・コンテキスト・プロンプト・RAG、この四つだと思う。これを理解してから、私は三国志カードゲーム制作でのAIの使い方を変えた。

それまでは、一つのAIに何でも聞いていた。企画も、仕様も、画面設計も、コードも、エラー修正も、カード効果も、文章も、改善案も、レビューも、全部を一人の万能AIに頼もうとしていたのだ。しかし、それはうまくいかなかった。

そこで、AIを一人の天才として使うのではなく、チームとして使うことにした。企画担当、仕様整理担当、UI/UX担当、カードバランス担当、コード生成担当、デバッグ担当、レビュー担当、マスターレビュー担当。役割を分けたのだ。

企画担当にはゲーム体験を考えさせる。仕様整理担当には曖昧さを洗い出させる。UI/UX担当には画面の情報量を見させる。カードバランス担当には弓・盾・計略・武器の強弱を見させる。コード生成担当には実装単位を小さく切って依頼する。デバッグ担当にはエラーの原因候補を洗わせる。レビュー担当には仕様と実装のズレを指摘させる。

さらに、LLMも用途によって分けた。全体設計や構造化に強いAI、文章の自然さや読みやすさの確認に強いAI、調査や大量情報の整理に強いAI、コード支援に向いたAI、レビューに向いたAI。もちろん絶対の正解はないし、モデルの性能は日々変わる。用途によって向き不向きも変わる。それでも、AIを一つの黒い箱として扱わないことがポイントだ。

LLMごとに得意・不得意がある。同じ問いでも、返ってくる答えの傾向が違う。文章が自然なAI、構造化が得意なAI、コードに強いAI、大量情報処理に強いAI、外部サービスとの連携が得意なAI、慎重なレビューに向いているAIそれぞれを使い分けることで、ようやく前に進み始めた。

LLMごとに特徴が出る理由も、今なら少し分かる。学習データが違う。モデルの構造や規模が違う。事後学習やチューニングが違う。ツール連携が違う。出力ポリシーが違う。どれも次トークン予測をしている点では同じでも、何を学び、どう調整され、どんな道具とつながっているかが違うため、運転感覚が変わってくる。

車で言えば、軽自動車、セダン、スポーツカー、トラック、バスが違うようなものだ。どれも車だが、加速、視界、荷物の積み方、曲がり方、得意な道が違う。LLMも同じである。

だから、生成AIを使いこなすには、単に「AIを使う」のではなく、用途に応じてAIを選ぶ必要がある。文章を磨きたいのか、構造化したいのか、コードを書きたいのか、大量資料を読みたいのか、調査したいのか、企画を広げたいのか、慎重にレビューしたいのか。目的によって、使うAIを変える。そして、AI同士を組み合わせる。

この発想に切り替えてから、三国志カードゲーム制作は少しずつ前に進み始めた。AIが急に賢くなったのではない。私がAIを一つの黒い箱として扱うのをやめたのである。

AIに丸投げするのをやめた。役割を分けた。前提を整えた。出力を小さくした。レビューを入れた。文脈を管理した。必要な情報を参照させた。最後の判断は人間が持つようにした。すると、少しずつ前に進み始めたのだ。

これは、会社の仕事でもまったく同じだと思う。

生成AIは、個人の時短ツールではなく、仕事の設計を問う道具である

多くの会社では、生成AIを個人の時短ツールとして導入しようとしている。メールを速く書く、議事録を速く作る、資料を速く作る、調査を速くする。もちろん、それは意味がある。

しかし、それだけでは仕事は減らない。会社の仕事は、個人作業だけでできているわけではないからだ。

仕事には目的がある。前工程があり、後工程がある。承認がある。責任分界がある。顧客がいる。法務がある。情報システム部門がある。現場の抵抗がある。暗黙知がある。過去の経緯がある。

AIで自分の資料作成が速くなっても、その資料が後工程で修正だらけになれば、全体の仕事は減らない。AIで会議メモが速くなっても、会議そのものが減らなければ仕事は減らない。AIで改善案が出ても現場が動かなければ業務は変わらないし、AIでコードが書けても仕様が曖昧ならプロダクトは完成しない。

三国志カードゲームでも同じだった。武将カードを作るのは速い。カード効果の案もすぐ出るし、画面レイアウトもコードもすぐ出る。でも、ゲーム全体の体験は、勝手には整わない。

どのカードを見せるのか。どの情報を隠すのか。どの判断をプレイヤーに委ねるのか。どこで迷わせるのか。どこで快感を出すのか。どこまでを初版に入れ、どこから先を次版へ送るのか。これは人間が決める領域だ。

つまり、生成AIは個人作業を速くする。しかし、仕事全体を良くするには、仕事の設計がいる。

ここで、生成AIの解体図が効いてくる。LLMを知ることで、AIを過信しなくなる。Transformerを知ることで、LLMが文脈のどこに注目しているのかを理解できる。パラメータを知ることで、AIが知識をデータベースのように保存しているわけではないと分かる。コンテキストウィンドウを知ることで、AIの視界には限界があると分かる。コンテキストを知ることで、前提を整えるようになる。プロンプトを知ることで、出力を制御できるようになる。RAGを知ることで、社内ナレッジや外部情報の整備が効くと分かる。そしてAIチームを組むことで、一つのAIに丸投げしなくなる。

これは単なるAI活用術ではない。仕事の進め方そのものを変える話である。

会社員は、AIに仕事を奪われるのではない

生成AIの話になると、必ず出てくる不安がある。AIに仕事を奪われるのではないか、という不安だ。

この不安は自然だと思う。私自身も、最初に生成AIを使ったとき、そう感じた。文章も書ける。資料も作れる。コードも書ける。アイデアも出せる。要約もできるし、壁打ちもできる。これなら、自分の仕事はいらなくなるのではないか、と。

しかし、実際に使ってみて、少し見方が変わった。

会社員は、AIに直接仕事を奪われるのではない。AIを使える人に、仕事の主導権を奪われるのだと思う。

AIを使える人は、仕事の立ち上がりが速い。論点整理が速く、調査の幅も広い。たたき台をすぐ作れるし、複数案を比較できる。レビュー観点を持ち、自分の思考をAIで拡張できる。一方で、AIを使えない人は、これまで通り自力でゼロから始める。この差は、少しずつ開いていく。

ただし、ここで使う「AIを使える人」は、単にプロンプトをたくさん知っている人ではない。AIの仕組みを理解している人である。

LLMのインプットがコンテキストであることを知っている。LLMは、コンテキストの次に来るトークンを予測し続けていることを知っている。プロンプトはコンテキストの一部であることを知っている。RAGもまた、外部情報をコンテキストに差し込む仕組みであることを知っている。LLMの中核にTransformerがあることを知っている。パラメータに学習結果が分散的に刻まれていることを知っている。コンテキストウィンドウという視界の限界を知っている。出力をレビューできるし、人間が判断すべき場所を分かっている。

そういう人が、AIを使える人である。AIを使える人は、AIに仕事を丸投げしない。AIを運転するのだ。

免許を取るように、AIを使いこなす側に回ろう

車は危険な道具である。使い方を間違えれば、人を傷つける。だから、免許があり、交通ルールがあり、教習があり、試験があり、最低限の知識が求められる。

生成AIも、これから仕事の中でますます大きな力を持つ。文章を作る。資料を作る。コードを書く。社内情報を検索する。意思決定を補助する。顧客対応を支援する。業務プロセスに入り込む。AIエージェントとして実際の操作を進める。

この力を無免許で使うのは危ない。もちろん、生成AIは怖いから使うな、という話ではない。むしろ、使わない方がリスクになる時代が来ている。だからこそ、免許を取るように、最低限の仕組みを学ぶべきだと思う。

AIを作る側にならなくてもいい。しかし、AIを使いこなす側には回った方がいい。

LLMは、コンテキストを入力として受け取る。LLMは、そのコンテキストの次に来るトークンを予測し続ける。プロンプトは、コンテキストの一部である。RAGは、外部情報をコンテキストに差し込む仕組みである。この核心を理解するだけで、AIの使い方は変わる。

会社でAI活用の号令が出た。でも、仕事は減らなかった。AIソロプレナーとして三国志カードゲームを作ろうとした。でも、一発ではうまくいかなかった。

その失敗を通じて、ようやく分かった。必要なのは、AIにうまくお願いすることだけではなかった。AIを安全に運転するための基礎知識だったのだ。

生成AIは、まだ完成されたオートマ車ではない。自動運転車でもない。今はまだ、クラッチ、ギアチェンジ、半クラッチ、エンストの感覚を知りながら扱うマニュアル車に近い。

だから、会社員には生成AIの免許証が必要である。AIに仕事を奪われる側ではなく、AIを使いこなす側に回るために。AIを怖がるのではなく、AIを運転するために。そして、仕事を単に速くするだけでなく、仕事の品質そのものを高めるために。

生成AIを使う時代は、もう始まっている。次に問われるのは、AIを使うかどうかではない。AIを無免許で使うのか。それとも、仕組みを理解して運転するのか。それだけである。