※年次のうち「頃」がつくものは記憶からの推定である。確定している日付はアプリのリリース日(2023年4月)などごく一部しかない。

はじめに

私は教育者である。そして、プログラミングがほとんどできない。

それでも、この2年ほどの間に、席替えアプリ、教材サイト、仕事用の小さなツールなど、数十のソフトウェアを作って公開してきた。書いたのは私ではない。AIである。私がやったのは、発想と、判断と、許可だけだ。

この記事は、教育に関わる立場で本気でAIを触ってきた経験から、「ここ2年程度はこれが当てはまるだろう」と考えていることをまとめたものである。結論を先に書いておく。

  • プログラミングは、できなくてもよい場合がある。その境界線は責任である。
  • ただし、次を作り続けるためには理解が要る。そして今、理解こそがボトルネックになっている。
  • 理解のコストを下げる方法もまた、AIにある。自分のコードの教材を、AIに作らせればよい。

この結論に至るまでに、私がいかにプログラミングを「してこなかったか」を先に書く必要がある。長い前置きになるが、これは「もともと書ける人がAIで加速した話」ではなく、「書けない人間がAIでものを作れるようになった話」であることを示すために必要な前置きである。

第1章 プログラミングとの出会い

高校まで:プログラミングと無縁だった

私は高校卒業までプログラミングをしたことがなかった。高校時代は部活に明け暮れ、授業では寝て、成績は悪かった。ちなみに部活も大した成績を残せなかった。本当は数学の先生になりたかったが、勉強についていけず、教育系の大学の技術系の課程に進学した。数学の免許は副免許という制度で取れると聞いたからである。

父のRubyプログラム事件

大学に入ってから、数学免許のための授業(幾何学か代数学か忘れた)でペア発表をすることになった。ペアが超優秀な子だったので丸投げして放置していたら、その子から裏で「何もせんやつ」と言われていることを知り、焦った。発表の3日前くらいの夜、父親に泣きついた。

父は、私が高校時代に使っていた電子辞書を改造してゲームを入れるくらいにはパソコンオタクだった。父はRubyでパーフェクトシャッフルのプログラムを作ってくれた。それをペアの子に渡すと態度が一変し、SNSで絶賛され、私は周囲から「プログラミングできるやつ」になってしまった。今思い返せば配列を使った簡単なプログラムだったが、このとき私はプログラミングの有効性を知った。普段は褒めない大学の先生からも褒められて、気分を良くしたのを覚えている。

余談だが、父の言葉で好きなものが2つある。ひとつは「Don't think, do」。今ならわかるが、ブルース・リーの Don't think, feel をもじったもので、合っているかわからないプログラムの前で固まっている暇があったら、実行してエラーメッセージを読め、というニュアンスだったと思う。私は生徒に「手を動かせ」という意味で使っている。もうひとつは「怠惰たれ」。これはプログラミングの本質だと思う。なぜプログラミングをするのか。楽をするためである。だから私は今も、楽をするためにAIを使っている。この2つの言葉は、この記事の最後まで通奏低音として流れる。

Arduinoと自作キーボード:授業を3回休めた話

その後、大学の授業でArduinoやScratchを使ったプログラミング学習を経験した。ある授業で「なんでもいいからモノづくりをしてください」という課題が出て、私はArduinoで自作キーボードを作った。買ったのはArduino Leonardoで、これはUSB機能を内蔵したチップを積んでいるため、パソコンにUSBキーボードとして認識させられる。つないで、ネットからプログラムを取ってくれば、すぐ実装できた。先生が一番苦労すると思っていた「USBをパソコンに認識させる」部分を一瞬でクリアしてしまったため、授業3回分を休んで過ごせた。それで単位をくれた。

ここまでの私は、プログラミングを「ちゃんと」していない。ネットから取ってきて動かしただけである。だが、振り返るとこの経験は今のAI開発とよく似ている。書けなくても、持ってくれば動く。動けば価値がある。

休講botと、価値のなかった卒業論文

なんだかんだプログラミングに興味を持ち、進んだゼミは、そのArduinoで単位をくれた先生のところだった。先生の専門は電子回路で、プログラミングはほとんど独学になった。最初に着手したのは、何を思ったか、大学の休講情報をつぶやくSNSボットの作成だった。Raspberry Piで勝手につぶやくようにし、朝の天気予報も入れた。これが、私が初めて「ちゃんと」プログラミングをした経験だったと思う。

卒業論文はScratchについて書いたが、はっきり言って研究としての価値はないと思う。やったことは、こうだ。学校の先生がScratchを使うと、生徒が音を鳴らしたり、機能がありすぎて脱線する。プログラミングが苦手な先生には不便だろう。そこで、ダウンロード版Scratch 3のコマンドブロックを画面から消せるようにした——。

Scratchの生みの親であるミッチェル・レズニック博士は、「低い床、高い天井、広い壁」、つまり誰でも入れて、高いところまで行けて、多様な方向に広がれる環境を大切にした人である。私の卒論は、その「広い壁」を真っ向から否定して壁を狭くする、最高に皮肉な内容だった。そんなわけのわからない論文を書かせてくれた指導教員には、とても感謝している。

一方で、Scratch Day でレズニック博士の講演を聞きに行ったことは覚えている。そこで聞いた4つのP(Projects, Passion, Peers, Play)と低い床、高い天井、広い壁という言葉を、私は今も教育で重要なものとして活動の軸にしている。そういう意味では、Scratchを研究した甲斐はあったのかもしれない。

もうひとつ思い出した。大学時代、ジムの受付でバイトをしていた。掃除以外は基本的に暇だったので、サボりつつできることを考え、集計に使っていたExcelのVBAでオセロを作ろうとした。中途半端に作って、完成しなかった。完成しなかった、というのが当時の私の実力である。

第2章 大学院と、プログラミングをしてこなかった私

大学院に行くきっかけは2つある。ひとつは、4年時に受けた教員採用試験に落ちたことだ。教育実習で生徒と揉めまくり、その校種の難しさを痛感したので、逃げるように別の校種を受けたのに、落ちた。

もうひとつは、他大学から来て授業をしてくれていた、ある先生の授業である。受講者はなんと私ひとりで、情報についていろいろ教えてもらった。感動したのは、私が質問した内容について「それについて話せるようにパワポあるねん」と資料を出してきてくれたことだ。この人の情報の知識はすごいのだろうと思い、進学を決意した。

大学院では遊んでいたので、プログラミングはろくにしていない。先生には申し訳ないことをした。修士論文は、ビジュアルプログラミングで学んだ人がテキストプログラミングに移行する際に感じるギャップを、動画教材で是正できないかというもので、正直に言ってゴミだったと思う。ただ、先生がいろいろ助けてくれたおかげで修了できた。感謝している。

ここまでが前置きである。強調しておきたいのは、ここまで私はプログラミングをほとんどしていないということだ。趣味でやっていたわけでもない。休講botとVBAの未完成オセロと、人から持ってきたコードが、私の全実績である。

第3章 AIとの壁打ちからCLIへ

席替えアプリ:課金させたかった

働き始めてから、私は席替えアプリを作り始めていた。動機は正直で、課金させるアプリを作りたかった。ChatGPTがOpenAIから出たての頃で、AIが先か、作り始めたのが先かは覚えていない。

最初はブラウザのChatGPTとの壁打ちプログラミングだった。うまくいかず、SNSで「プロンプトエンジニアリング」という言葉に出会った。そこで痛感したのが言葉の重要性である。よく使われているUIの部品の名前がわからない。名前がわからないと、AIに聞くことすらできない。この「知らないことは聞けない」という感覚は、後で述べる「理解」の話の伏線になる。

大学院時代のプログラマーの友人に相談すると、一緒に勉強することになった。それから月1回〜半年に1回のペースで勉強会をするようになった。席替えアプリは、リリースまでこぎつけた。2023年4月のことである。

勉強会:人力のフロントエンドから、AI丸投げへ

友人との勉強会では、さまざまなものを一緒に作ろうとした。最初の頃は「今のAIの能力じゃ大したものはできない」ということで、フロントエンドの基礎を教えてもらった。React、Next.js、npm、Node.jsなど。ちなみにその友人は、今ではカンファレンスでトークを務めるくらいになっている。

では私がプログラミングできるようになったかというと、なっていない。Reactの値を保存するやつ(useState)で詰まっていたくらいで、ほとんどできていなかった。Reactチュートリアルの五目並べをやった人なら、あれの序盤で詰まるレベル、と言えば伝わると思う。

しばらくすると、AIを使えば簡単なWebページができるようになってきた。「一緒に開発しよう」と言いながら、実際は私がAIに聞き、友人が実装を確かめる、という分担になっていた。何年目かには文章の自動採点アプリを作ろうとして、安いトークンで動かすために友人にLangChainなどを勉強してもらった。私はわからなかったので、丸投げした。

この勉強会で、私はついぞ、プログラミングに正しく取り組めないことがわかった。私は、AIに頼ったプログラマーになった。

CLIツール:許可するだけの開発

その友人にCLIツール(ターミナルから使うAIコーディングエージェント)を教えてもらったことで、AIへの依存はさらに進んだ。作り方にはいろいろ変遷があったが、落ち着いたのはこうだ。

  1. Next.jsやTanStackなどの適当なテンプレートで、npmでプロジェクトを作る
  2. AIに「こんなものを作りたいから、仕様書を作って。質問もして」とお願いする
  3. 仕様書を適当に確認して、実装の許可を出す

これだけである。このサイトのツール群も、私の開発フォルダにあるものの多くも、この方法で作っている。

第4章 いまの作り方 — カンバン方式と複数エージェント

最近は「カンバン方式」という進め方に一旦落ち着いている。これも例の友人に教えてもらった。この方式が最初に確立したのはGodot製ゲームの開発(2026年7月にカンバン導入)で、そこで固まった仕組みを、翌月に立ち上げた別のゲーム開発リポジトリへ丸ごと移植した。つまり私の手元には、方式の第1世代(試行錯誤と事故の記録)と第2世代(洗練された移植先)の両方が残っている。知らない人が多いと思うので、第2世代のリポジトリを例に、初学者向けに説明する。以下はすべて、2026年8月時点で実物のファイルとして存在するものである。

カンバンとは:付箋を貼るホワイトボード

カンバン(看板)とは、もともとトヨタの生産方式に由来する仕事の見える化の方法で、要するに「やること」を1枚ずつカードに書き、ホワイトボードの上を「未着手 → 作業中 → 完了」と動かしていくやり方である。ソフトウェア開発では Trello などのツールが有名だが、私のプロジェクトでは、このカンバン自体をAIに作らせた。ReactとHonoで書かれた自作のWebアプリで、データはデータベースではなく、ただのJSONファイルに入っている。開発を管理する道具そのものを、まずAIに作らせる——これが「開発環境をAIに作ってもらう」の一例である。

このカンバンの中心思想は、仕様書に一文で書いてある。

カードの本文が、そのまま実行プロンプトになる。

つまり私は「AIへの上手な指示文(プロンプト)」を書く必要がない。「やってほしいこと」を日本語でカードに書けば、それがそのままAIへの指示になる。列(カードの状態)は5つだけで、「AIタスク」「実機確認」「判断待ち」「保留」「完了」。誰が動かすかも決まっていて、「AIタスク」を拾って進めるのはAI、「実機確認」(実際に動かして遊んでみる)と「判断待ち」を処理するのは人間である。

実際のログを集計すると、カードを動かした回数は人間(ブラウザ操作)が531回、AIが409回。カードのコメント欄はAI 292件・人間228件で、ほぼ人間とAIの対話ログになっている。開発の会話が、チャット履歴ではなくカードに残るのがミソで、AIは毎回まっさらな記憶で始まるが、カードを読めば文脈を取り戻せる。

複数エージェント:親が配るのではなく、盤がハブになる

「一人のエージェントから複数のエージェントに指示を出してもらう」と私は理解していたが、実物を確認すると、正確には少し違った。親エージェントが子に直接配るのではなく、カンバンの盤がハブになっている。カードには担当者欄があり、AIモデル名や「人間」「自動」から選ぶ。担当者にAIモデル名が書いてあれば、そのモデルのエージェントが起動されて仕事をする。「自動」なら、内容を見てAIが振り分ける。人間の私は、担当者を選ぶことすら省略できる。

役割分担も明文化されている。人間の仕事は4つだけ——やりたいことをカードに書く、判断待ちを判断する、実機で遊んで確認する、不可逆な操作(公開・デプロイ・課金)を承認する。それ以外の実装・調査・検証は、全部AIである。

git worktree:同じプロジェクトの分身を作って並行作業

もうひとつの道具が git worktree である。gitに詳しくない人向けに言うと、同じプロジェクトのフォルダの「分身」をもう1つ作り、別の作業を並行して進められる機能だ。分身の中でAIが作業し、うまくいったら本流に取り込む。私のプロジェクトでは、この取り込み(マージ)にルールがあり、書いた本人ではない別のAIに差分を読ませてレビューさせないと、取り込みコマンドが通らないようになっている。実際、わざと規約違反のコードを入れた枝を読ませたら、行番号付きで指摘されて取り込みが止まった。

事故から規則が生まれる

面白いのは、この仕組みの規則の多くが事故から生まれていることだ。たとえば、テストを回しただけで本番の盤にダミーのカードが21枚並んでしまった事故があった。そのとき作られた規則は「気をつける」ではなく、「気をつける、で守らない」——同じ事故が構造的に起きないよう、コードで防ぐ。人間の職場の再発防止と同じことが、人間とAIのあいだで起きている。

これもその友人に教えてもらったことの延長線上にある。そのとき聞いた言葉が、ずっと残っている。

「人間がボトルネック。人間の発想がボトルネック。」

コードを書く速度はもう制約ではない。人間が何を作りたいか思いつく速度、人間が判断する速度が、開発全体の律速になっている、という意味である。

さらに最近は、開発環境そのものをAIに作ってもらうようになった。自分が開発しやすい環境をどう作っていくかが、腕の見せどころになっている。

こうして私は、父の言う Don't think do を実現した。私の頭の中で、何も考えずにプログラムができてしまう。ただしこれは、悪い意味での「考えるな、実行しろ」である。教えてもらっていた頃は、AIのコードを多少なりとも理解しようとした。だが怠惰な私にはできなかった。そのうち、確認をバイパスして、私の許可すら取らずにAIが実行していくようにしてしまった。

第5章 プログラミングは、できなくてもよいのか

ここまでで、私の結論は「プログラミングは、できなくてもよい」である。

ただし、これは私の立場だからできなくてもよい、という意味だ。プログラマーはプログラミングができないと困ると思う。

生徒には、こう言っている。責任を取る必要が自分にあると思うなら、ちゃんと読め。

ここでの責任とは、誰かに使ってもらう際に、その人に損害が生じたときに賠償することを前提とした責任である。私の作るものはすべて、責任を持たなくていいように作っているつもりだ。無料で、ブラウザで動いて、壊れても誰も損をしないもの。その程度のプログラムしか書かないのであれば、読めなくてもよいと思う。逆に、このプログラムに自分で責任を持ちたいと思うなら、それ相応の覚悟——つまり理解——が必要である。

この「ちゃんと読め」は、もともと競技ロボットに打ち込む生徒に向けて言った言葉だ。勝ちたいのに、自分のロボットのプログラムを読めないなら、その結果に責任は持てない——そういう意味である。

「できなくてもよい」は無条件ではない。責任の範囲が、読むべきコードの範囲を決める。これが、生徒に伝えている境界線である。

第6章 理解がボトルネックである

Geoffrey Litt の "Understanding is the new bottleneck"(2026年7月)という記事に出会って、この考えはさらに深まった。コードを書くことがボトルネックだった時代は終わり、人間の理解がボトルネックになった、という主張である。現状の私が、まさにこれだと思う。

理解には時間がかかる。コストがかかる。では、コストがかかるのであれば、理解する必要はあるのか。

答えは、ある。

プログラミング(コードを書くこと)はAIに任せてよい。しかし理解しておくと、次の実装のときに役に立つ。なぜそう言えるか。理解していると、指示の具体性が増すからである。わからないことはAIに聞けばよいが、知らないこと——何を聞けばいいかすらわからないこと——は、聞くこともできない。第3章で書いた「UIの部品の名前を知らないと質問できなかった」体験が、まさにそれだ。そして一度理解したことは、細部を忘れても、その方法を使うことができる。今のカンバン方式が普通に使えているのは、多少の理解があったからである。

一方で現状の私は、開発が速すぎて、ソースコードをまったく見ていない。それで今は困らない。だが、それでは次の段階に進むことが難しい。

こう考えている。AIが作るものが完成品だとしたら、プログラムは部品である。部品のひとつひとつを理解する必要はない。しかし、アプリ開発がこれほど楽になったAI時代に、「次」を作らないのは逆に損である。そして、次々にものを作り出すためのエンジンになるのが、理解なのだ。

だからこそ、理解が必要になる。しかし、その理解こそがボトルネックである。コストが高い。では、どうするか。

第7章 では、どう理解するか — 教材を作ってしまえばいい

Litt が示唆するように、教材まで作ってしまえばいいのである。

アプリ開発のコストが劇的に下がった。ということは、「いま自分が作ったプログラムを理解するための教材」を作るコストも、同じように下がっている。自分のコードを題材に、AIに解説サイトを作らせる。問題までつけさせる。それを自分が読む。読めば、次の指示が具体的になる。次が作れる。

私はいま、実際にこれをやっている。第4章で紹介した第2世代のリポジトリには、カンバンの仕様書と並んで「自分たちのコードを題材にした教材サイト」の仕様書が置いてあり、作ったコードの教材化までがひとつの開発フローに組み込まれている。あのフォルダの中身が、この問いへの私の現時点の答えだと思っている。

これは教育の話でもある。プログラミング教育は長らく「書けるようになること」を目標にしてきた。しかし、書くことがAIに移った今、教えるべきは読んで理解し、具体的に指示し、責任の範囲を判断する力ではないか。レズニックの「低い床」は、AIによってかつてなく低くなった。床が低くなった分、そこから「高い天井」へ登る梯子が理解であり、その梯子すらAIと一緒に作れる時代になった——というのが、2年間触り続けた私の現時点の結論である。

おわりに

最後に。私は、AIができてからのモノ作りは最高だと思っている。否定する人もいるが、私のできないプログラミングを丸投げできる、最高の相棒である。

父は「怠惰たれ」と言った。プログラミングは楽をするためにある。私は楽をするためにAIを使い、楽をした分で、次のものを作っている。

だから、このWebサイトのモットーは「AIは友達」になっている。

追記 — この記事を公開する直前のこと

この記事を公開する準備の最中に、私はAIに、こう送った。

この記事に価値があるか自信がありません。価値なしと思ったら、きちんと伝えてください。これを残すことに不安を感じています

AIの答えは、こうだった。主張だけを取り出せば新しくない。「AIで書けなくても作れる」「理解が大事」という意見は、すでに世界中で書かれている。意見だけの記事なら価値は低いと伝えていた。この記事の価値は意見ではなく記録にある。書けない人間が2年間委譲し続けたら何が起きたかという一次資料はほとんどなく、価値は読まれる数ではなく、残ることそのものにある——。

私は、残すことに意味があると言うのであれば残す、と決めた。そして、この相談のやりとりも記事に残すことにした。

気づいた人もいると思う。これは、この記事に書いてきたことそのものである。人間が問い、AIが根拠を挙げて答え、最終決定は人間がした。発想と判断は人間、それ以外はAI。この記事の最後の1ページまで、その分担でできている。

参照文献