正直に言うと、僕はもともと読書家ではありませんでした。AIと対話しながら一冊を読み解く「読書体験3.0」を覚えてから、ようやく本の面白さがわかってきた口です。今回の本は、その「AIと対話しながら」をアプリづくりでやってみよう、という一冊でした。読みながら手を動かしたくなる本は、久しぶりです。
今回取り上げるのは、安藤昇さんの『それ、AIで作れます。 だれでもたった1日で役立つアプリが作れる本』（幻冬舎、2026年7月）です。著者は青山学院中等部で情報とプログラミングの講師を務め、スタディサプリの情報I講師、青山学院大学の非常勤講師でもあります。全国の学校で生成AIの活用を支援し、YouTubeチャンネル「GIGAch」は登録者数3万人を超えています。
僕がこの本を手に取ったのは、社会人向けにバイブコーディングの講座を開いている立場として、同じ壁を何度も見てきたからです。AIに頼めば最初の画面はすぐにできる。ところが、少し直したら前の機能が動かなくなる。どれが最新のファイルかわからなくなる。そこで手が止まり、やめてしまう人が多い。本書は、中学生を主人公にしながら、この壁の越え方をいちばん丁寧に書いていました。
最後まで読むと、「プログラミングは専門家のもの」という前提が外れます。同時に、AIに作らせたものを壊さずに育て続けるための、保存と試行の習慣が身につきます。
この本はどんな本か ―― 「仕組みを作る側」に回るための入門書
クリックすると、その見出しへ移動します。
目次14項目
この本はどんな本か ―― 「仕組みを作る側」に回るための入門書
▲ 言葉で作り、育て、公開し、立て直す本書の全体像の図解
本書の出発点は、「はじめに」に置かれた一つの見立てです。生成AIが広まり、文章やイラスト、資料をAIに作ってもらうのは当たり前になった。その次に変わるのは、誰もが「仕組みを作る」側に回れるようになることだ、と。
『AIと会話するだけで、アプリの仕組みを作ることができる』（「はじめに」）
構成は4部です。第1部でGoogleのGeminiに話しかけ、言葉がそのままアプリになる感覚をつかむ。第2部でGitHubとCodespaces、GitHub Copilot CLIという本格的な道具に進み、作品を保存しながら育てる方法を覚える。第3部で、著者が用意した教材アプリを自分のリポジトリにコピーし、自分用の学習ログアプリに育てて公開する。第4部で、エラーや思いどおりにならないときの立て直し方を学ぶ。
登場人物は、バイブコーディングのマスター「コーダ」と、中学生のサラとユウマです。語り口は中学生向けにやさしいのですが、著者自身が『高校生や大学生、それからAIをどう使うべきか学びたい大人にも十分役立つ内容だ』と書いているとおり、社会人が読んでも物足りなさはありませんでした。むしろ、大人向けの本が省きがちな「なぜその手順が要るのか」まで書いてある分、初めての人にはこちらのほうが親切だと感じます。
この本の目的は、プログラマーやアプリ開発者を育てることではない、と著者ははっきり書いています。困ったときに、自分に合う道具を自分で作って状況を変えられる人になるか、誰かが作るのを待つ人のままか。その差が、勉強にも仕事にもじわじわ効いてくる、という問題意識が全体を貫いています。
第1部「言葉でアプリを作る体験」 ―― AIには命令ではなく、相談する
▲ 命令と相談の違いと、会話でアプリを育てる流れの図解
第1部は、Geminiに「クイズゲームを作って」と打ち込むところから始まります。本当にそれだけで、選択肢を選ぶとスコアが上がるクイズアプリが動く。著者はこの光景を初めて見たとき、プログラミングを何年も教えてきた身として信じられない気持ちだった、と書いています。
著者はここで、AI研究者アンドレイ・カーパシーの言葉を引きます。
『今最も熱いプログラミング言語は母国語だ』（第1部 第1章）
続く章では、シューティングゲーム、勉強用のポモドーロタイマー、テストの点数計算機、英単語の単語帳、お絵描きアプリ、花火のアニメーションと、言葉だけで作れるものの幅を体験していきます。どれも最初の一言で土台ができ、「宇宙船の動きをもっと速くしたいんだけど」「BGMをつけたいな」と話しかけるたびに育っていく。
「正しい命令」より「いい相談」
第1部で僕が最も大事だと感じたのは、第2章の会話のコツです。
『Geminiへの話しかけ方は、「命令」ではなく「相談」だと思おう』（第1部 第2章）
「爆発エフェクトを追加しろ」と命令すれば、言われたことだけが返ってくる。「敵を倒したときの達成感をもっと出したいんだけど、何かいい演出ない?」と目的ごと相談すれば、効果音やスコア表示の工夫まで提案が返ってくる。著者は、今のAIは目的を理解して最適な方法を一緒に考えてくれる存在だから、正しい命令を出そうと頑張るより、いい相談をするほうが結果がいい、と説明します。
これは、社会人向けの講座でもまず伝えたい点です。大人は仕事で指示を出し慣れているぶん、AIにも短い命令を打ちがちです。けれど、やりたいことの背景を一言添えるだけで、返ってくるものの質が変わる。中学生向けの本で、この要点が最初の章に置かれているのは的確だと思いました。
第1部の締めくくりは、自分でテーマを決めたオリジナル作品です。困っていること、好きなこと、誰かを喜ばせたいこと。この三つからアイデアを探し、最後に作品に名前をつける。『名前をつけると、それは「ただのアプリ」から「自分の作品」になる』という一文には、教育者としての著者の温度が出ていました。
第2部「本格的なバイブコーディング」 ―― セーブポイントと平行世界を手に入れる
▲ コミットはセーブポイント、ブランチは平行世界の図解
第2部の入口で、著者は読者が抱きそうな疑問に先回りしています。「もうGeminiだけで十分じゃない?」。答えは、作品が育つとAIがどんどんコードを書くので、ファイルが増え、どこを直せばいいか、どれが最新か、前の状態にどう戻すかがわからなくなるからだ、というものです。Geminiがだめなのではなく、役割が違う。この説明の順番がうまい。
ここから使うのが、GitHub（作品の置き場所）、Codespaces（ブラウザの中の作業場）、GitHub Copilot CLI（ターミナルで動く相談相手）です。GitHubを「プログラムのYouTube」、Copilotを「副操縦士」、ターミナルのCopilot CLIを「ターミナルで動く相談相手」と、身近な言葉に置き換えながら進めてくれます。
MVPで始め、一つずつ直す
第8章では、Copilot CLIに「横スクロールアクションゲームをMVPで作りたいのだけどどうすればいい?」と相談します。MVPは「まず動かせる最小限の形」。プレイヤーが動く、敵をよける、スコアがわかる。この三つができれば遊べる、と決め、かっこいいグラフィックや複数ステージは後回しにする。最初から全部盛りにすると、AIへの相談もぶれやすいからです。
そして第10章では、一気に全部変えないことを繰り返し説きます。一つだけ相談する。動かして確認する。問題なければ保存する。次の相談に進む。見た目を整える、敵の速さを調整する、スコアを目立たせる、ゲームオーバー画面をつける。この順で一つずつ直すと、どこでおかしくなったかを見失いません。
相談の前に「説明メモ」を渡しておく
第9章で、直す前にやっておく準備として紹介されるのが「/init」というコマンドです。これを実行すると、Copilotがプロジェクトの中身を読み取り、どんなファイルがあり、どういう仕組みで動いているかをまとめた説明メモを作ってくれる。以後の相談では、このメモが毎回参照されるので、「ぼくのゲームはこのファイルとこのファイルでできていて」と説明し直さなくて済む。著者はこれを、アルバイト先に新人さんが入ってきたときに、お店のルールを書いたメモを渡すようなものだとたとえています。返答が英語になったら、このメモに「説明は日本語で」と一行足せばいい、という実用的な助言も付いています。
同じ章には、利用量の上限が近づいたときの心得もあります。上限が近いと、まとめて頼まなければと思いがちだが、むしろ逆で、相談を一つにしぼり、小さく直し、区切りごとにコミットしておく。道具の制約に合わせて作業の粒度を変える、という考え方は、大人がAIを仕事で使うときにもそのまま通用します。
コミットはセーブポイント、ブランチは平行世界
第2部の核心は、変更を保存する仕組みの説明です。
『コミットは、ゲームでいうセーブポイントみたいなものだ』（第2部 第7章）
コミットは今の状態に名前をつけてセーブすること。変更の同期（プッシュ）は、そのセーブをGitHubの倉庫に送ること。二つをセットにして「コミット&変更の同期」と呼び、小さな変更ごとに必ず行う。著者は、コミットの履歴がグラフに「足あと」として残り、Copilotに頼めばどの時点にも戻れることを実演してみせます。
さらに第11章では、ブランチを「平行世界」と呼びます。本編のmainはそのまま残し、ネオン風デザインの世界とレトロゲーム風デザインの世界を別々に作って見比べ、気に入ったほうだけをmainに合流させる。コミットが時間軸の記録なら、ブランチは別バージョンを並行して育てる仕組みだ、という対比は、大人向けの解説書よりずっとわかりやすいと感じました。
最後の第12章でGitHub Pagesを使って作品を公開し、URLを送れば誰でも遊べる状態にします。公開前に個人情報やパスワード、他人の画像や音楽が入っていないかを確認する、という注意も欠かさず書かれています。
第3部「自分だけのアプリを育てる」 ―― ゼロから作らず、借りて育てる
▲ 公開アプリを借りて自分用に育てる手順の図解
第3部の発想は、ゼロから作らないことです。著者が用意した教材用の「かんたん日記」アプリを自分のリポジトリにコピーし、勉強の記録をつける学習ログアプリに育てていく。すでにある仕組みを生かし、自分の目的を言葉にして、AIに相談しながら必要な形に変える。著者はこれを、AI時代の個人開発の自然なやり方だと位置づけています。
見られることと、使ってよいことは別
コピーの前に、著者は二つのファイルを必ず確認させます。アプリの地図にあたるREADMEと、使い方のルールを書いたLICENSEです。
『見ることができることと、使ってよいことは別だ』（第3部 第13章）
教材のMIT Licenseは使いやすいライセンスだが、元のライセンス表示は消さずに残す。READMEにも何をもとにしたかがわかる表示を残す。第18章では、GitHubで見つけた他のリポジトリを使う前の確認手順まで扱い、ライセンスが見つからないもの、使ってよい範囲がわからないものはコピーして公開する題材にしない、と明言しています。中学生向けの本でここまで権利の扱いを丁寧に書いているのは、大人の読者にとっても良い手本です。
変える前に、まず動かす
第15章の「変える前に、まず動かす」も、実務でそのまま使える教えでした。変える前の状態を知らないまま編集すると、画面がおかしくなったときに原因がわからなくなる。だから元のアプリで保存、編集、削除、検索を一通り試し、観察しておく。
あわせて、アプリに入力した記録はGitHubではなくブラウザの中（ローカルストレージ）に保存されること、それはコードのコミットとは別の話であることも整理されています。「ローカル」という同じ言葉が、コードの作業場所とブラウザの保存場所という別々のものを指している、と先回りして区別してくれる。初心者がつまずく場所を、教える現場の経験から正確に知っている著者だと感じました。
第16章と第17章では、作業用ブランチで学習ログアプリに作り変え、公開前チェックをしてからmainに合流し、GitHub Pagesで公開します。このとき、Copilotへの依頼文に「LICENSEファイルは消さない」「個人情報は入れない」と、守ることまで書き込んでいる点も見逃せません。やりたいことと同じくらい、守りたいことを伝える。AIに仕事を渡すときの基本がここにあります。
第4部「うまくいかないときの対処法」 ―― エラーは直すための材料
▲ 困った画面の種類ごとにAIへ渡す材料の図解
第4部は、作り続けるうえで一番の関門である「うまくいかないとき」を扱います。著者はまず、エラーの見方を変えるところから始めます。
『エラーは「失敗」ではない。エラーは、アプリが「ここで困っているよ」と教えてくれているサインだ』（第4部 第19章）
そのうえで、困った画面の種類ごとに、AIへ何を渡せばいいかを整理しています。
- 赤いエラーが出たら、エラーメッセージを省略せずそのまま貼る。「なんかエラーが出ました」では、AIも原因を探しにくい。何をしていたか、何が起きたか、出ているエラーの三つをセットで伝える。
- 画面が真っ白なら、ブラウザのConsoleを見る。画面には出ない裏側のエラーがそこに表示される。エラーがないことも、それ自体が伝えるべき情報になる。
- エラーは出ないが思いどおりでないなら、期待と実際を分けて書く。期待していたこと、実際に起きていること、どこで起きているか。原因を自分で当てにいかず、見えていることを分けて言葉にする。
- 見た目がおかしいなら、スクリーンショットを見ながら言葉にする。どこが気になるか、どうなってほしいかをセットにする。画像を渡す前には、メールアドレスや本名が写っていないかを確かめる。
何度も直して中身が複雑になってきたら、「動きは変えずに、あとから直しやすい形にリファクタリングしてくれる?」と相談する、という助言も実用的でした。「動きは変えずに」の一言が、AIに勝手な変更をさせないための歯止めになる。こうした一文単位の工夫が、本書の随所にちりばめられています。
本書の専門語を、生活の言葉に置き換えると
本書は専門語を身近な言葉に置き換えながら進むので、初めての人でも読めます。それでも初見の用語をまとめておきます。
| 本の言葉 | やさしい言い換え |
|---|---|
| バイブコーディング | AIに相談しながら、作って、動かして、直すプログラミング |
| MVP | まず動かせる最小限の形。遊べる、使える、の最低ライン |
| GitHub | 作品のファイルと変更の履歴を置いておく倉庫 |
| Codespaces | ブラウザの中に用意できる自分専用の作業場 |
| Copilot CLI | 作業場の中で話しかけられるAIの相談相手 |
| コミット | 今の状態に名前をつけてセーブすること |
| 変更の同期（プッシュ） | セーブをGitHubの倉庫に送って写しを残すこと |
| ブランチ | 元の作品を残したまま試せる平行世界 |
| マージ | 平行世界で試した変更を、本編に合流させること |
| README／LICENSE | 作品の説明書／使ってよい範囲のルール |
| ローカルストレージ | アプリに入力した記録を、ブラウザの中にしまう場所 |
| リファクタリング | 動きは変えずに、中身を整理すること |
僕ならこう活かす ―― 大人の職場にこそ「それ、AIで作れます」を
▲ 職場の小さな不便を小さなツールに変える手順の図解
本書の「おわりに」は、中学生だけでなく社会人に向けた言葉で結ばれています。毎回手作業で作り直している表、見づらいまま使い続けているチェックリスト、人によってやり方がバラバラの入力作業。そういう小さな不便に対して『「それ、AIで作れます」と言って、とりあえず不便を解決する小さなツールを作ってみることができるはずだ』と。試してみてから、本格的に導入するときにプロの開発者に依頼すればいい、という線引きも現実的です。
僕なら、職場でこの本を使うときに次の三つを取り入れます。
- 最初の1時間は第1部だけに使う。大人の研修でも、いきなりGitHubから入ると手が止まる人が出やすいからです。まずは言葉でアプリが動く体験をして、「命令ではなく相談」を身体で覚えてもらう。
- 「コミット&変更の同期」を合言葉にする。本書の最大の価値は、作ったものを壊さずに育て続ける習慣を、中学生にもわかる言葉で定着させる点にあります。社内で小さなツールを作るときも、直したら保存して送る、を約束事にしておくと、後で誰かが引き継げます。
- 依頼文に「守ること」を必ず書く。本書の依頼文には、LICENSEを消さない、個人情報を入れない、関係ないファイルは触らない、が繰り返し出てきます。業務データを扱う大人の現場なら、なおさら必要な一文です。
一点だけ、読む前に添えておきたいことがあります。本書の画面や機能の説明は2026年4月時点の情報で、著者自身がボタンの名前や場所は変わりうると何度も断っています。また、第9章で紹介される確認を省くモード（/yolo）については、著者が仮想環境のCodespacesだから使えるのであって、自分のパソコンでは使わないこと、慣れたら確認する運用に戻すことを強く勧めています。ここは読み飛ばさずに押さえておきたい箇所です。
そして僕がいちばん信頼できると感じたのは、「おわりに」の次の一節でした。
『「文法やコードを学ばなくてよい」ということではないことを言っておきたい』（「おわりに」）
AIが書いたコードはいつも正しいとは限らない。コードを読めれば、本当に直っているのか、変更が大きすぎないかを自分の目で確かめられる。著者はそれを『AIの答えを鵜呑みにせず、自分で確かめられる力』と呼び、作ったアプリの中身を少しずつのぞき、気になったところをAIに「このコードはどういう意味?」と聞いてみることを勧めています。コードを一切使わない本の最後に、この一文を置く誠実さが、本書の品格を決めていると思います。
まとめ ―― バイブコーディングの始まりは、頭の中にあるアイデア
この本を一行に圧縮するなら、第2部の終わりのコラム「AIに任せること、自分で決めること」に置かれた一文になります。
『君の「作ってみたい」は、どんなコードより先にある』
コードを書くこと、エラーを読むこと、手順を整理することは、AIに任せられるようになった。けれど「これを作りたい」と思うことは、人間の中からしか出てこない。そして、作ったものを言葉で育て、壊さずに保存し、困ったら材料をそろえて相談する。本書は、その一連の流れを中学生にもわかる言葉で、一冊にまとめ切っていました。
AIでアプリを作ってみたいけれど何から始めればいいかわからない人、AIに作らせたものが途中で壊れて止まってしまった人、社内で小さな業務ツールを試してみたい管理職の方にとって、この本はいちばん丁寧な入口になります。まずはGeminiを開いて、「クイズゲームを作って」と打ち込んでみてください。気になった方は、一度手に取ってみてください。
最後までお読みいただき、ありがとうございました。
学びは、取り入れて初めて自分のものになります。
————————————————
佐藤勝彦 / TANREN株式会社