この記事は、漫画『葬送のフリーレン』の単行本11巻（黄金郷のマハト編）までの展開に触れます。未読の方はネタバレにご注意ください。

はじめに

「魔法というのはイメージの世界だ。……イメージできないものは魔法では実現できない。」

これは『葬送のフリーレン』で、フリーレンやゼーリエ、フランメといった魔法使いたちが語る魔法観だ[1]。読んだとき、これは『葬送のフリーレン』の中だけの話ではなく、現実世界に、ひいては個人開発にも当てはまると思った。魔法を「コードを書くこと」に置き換えても、そのまま成立する。

個人開発をしていると「できる気がしない」という感覚に何度もぶつかる。新しいアーキテクチャ、未経験の技術スタック、はじめて挑む仕様。しかし振り返ると、「できない」の多くは「まだイメージできていないだけ」だった。

ひとつ断っておきたい。この記事が扱う「できない」は、(a) 頭の中で手順をうまく分解できていないだけの「できない」だ。前提知識やスキル、時間そのものが足りない (b) の「できない」とは別の話で、こちらは分解の解像度を上げても埋まらない。本稿は (a) に絞る。

この記事では (a) の構造を整理し、最後に「イメージを広げる具体的な手順」へ着地させる。精神論では終わらせない。

1. 「イメージできる」とは何か

「イメージできる」とは、「完成までの手順を頭の中で最後まで再生できる」状態のことだ。もう少し操作的に言い直すと、実行可能なステップに分解されている状態。

たとえばUnityでプレイヤーが壁に当たって止まる処理を実装するとき。CharacterControllerのMove()を呼んで、CollisionFlagsで接触面を判定して、入力を0にする——と手順が浮かぶなら「イメージできている」。逆に「なんとかなりそう」しか浮かばないなら、まだイメージはない。

大事なのは「なんとかなりそう」と「イメージできている」は別物だという点だ。前者は感情、後者はメンタルモデル。感情に引きずられて「なんとかなりそう」で着手すると、進めるほど詰まる。「次に何をすればいいか言える状態か？」が判定基準になる。

これは作中で語られる魔法観と一致する。魔法使いは魔力を「どこへ」「どう働かせるか」をイメージして初めて術が発動する。手順が浮かばなければ魔法は起きない。コードも同じで、「書けばなんとかなる」は呪文を唱える前に倒れることを意味する。

2. 「イメージできない」とは何か

では、その限界の正体は何か。大きく規模と環境、二種類の「見えなくなり方」がある。この区別は後の§4・§5で再び効いてくるので、頭の隅に置いておいてほしい。

規模による限界は、直感が効かなくなることだ。1個のファイルを読んで処理するのはイメージできる。では、大規模システムで数億のファイルを捌くとしたら？　やることは同じ繰り返しでも、その規模になると分散処理が前提になり、メモリ・I/O・ネットワークの振る舞いが直感からずれていく。個人がふだん扱える量ではないし、ノードごとの遅延のばらつきや一部の失敗も当たり前に起きる。計算量は言えても、実際にどこがボトルネックになり、どこが壊れるかは、動かすまでわからない。「知っている」と「最後まで再生できる」は別だ。

環境による限界は、状況が変わるとメンタルモデルが崩れることだ。作中でフリーレン自身がこう言う——「水を操る魔法使いに雨の中で勝てるイメージが出来る？　少なくとも私は出来ない」[2]。千年以上生きた魔法使いが「イメージできない」と断言する。条件が変われば、それまでのモデルは使えなくなる。

個人開発でも「その技術は知っている」が「そのプラットフォームでは動かしたことがない」という状況はよく起きる。iOSで動いていたコードがAndroidで別の挙動をする、WebGLビルドでUnityのAPIが使えない——知識はあってもイメージはない、という状態だ。「できない」ではなく「まだイメージが追いついていない」と読み替えることが出発点になる。

3. 反論と再反論 ── 「イメージできなくても作れてる」

「でも実際、DBの仕組みを完全にイメージしなくてもSQLを書けているし、HTTPの実装を知らなくてもAPIを呼べている。イメージなんて要るの？」

この反論は正しい。しかし、なぜ使えているのかを考えると話が変わる。

DBエンジンの内部を誰かが設計し、コードに落とし、SQLというインターフェースとして梱包した。HTTP/1.1の仕様を誰かがRFCに定め、ライブラリが実装し、fetch()という一行に包んだ。誰かが代わりにイメージし、抽象化として届けてくれている。我々はその「借り物のイメージ」の上を走っている。

AIも同じ構造を持つ。「このコード書いて」と頼めばClaude Codeが出力する。しかしAIが生成できるのは、人類がすでにイメージし、訓練データに残してきた範囲だ。「誰もまだ実装したことがない仕様」「独自ドメインの複合ロジック」——そこではAIは止まる。あるいは止まったことに気づかず動いているふりをする。

個人開発の多くは、ゼロから未踏領域を切り拓く作業ではない。既存の部品を新しい組み合わせでつなぐ作業だ。自前のイメージが要るのは全工程ではなく、借り物どうしの「継ぎ目」で抽象が綻ぶ瞬間に集中している。ライブラリAの前提とライブラリBの前提が食い違う、想定外の入力で抽象が漏れる——そこだけは誰も代わりにイメージしてくれていない。だから、内部で何が起きているかを一段深く理解しようとする習慣には意味がある。借り物がどこまで効いてどこで切れるか、その境界を知っておくことが詰まらずに進む条件になる。

4. 「信じれば何でも」ではない ── 本物の限界

ここで§2の二分類が効いてくる。あそこで挙げた「規模の壁」は、多くが「難しいだけ」に落ちる。一方「環境・外部制約の壁」は、そのまま「不可能になりやすい」壁だ。挑戦マインドの話をすると「強く信じれば不可能はない」方向へ滑っていく。だが「難しいだけ」と「物理的に不可能」は別物で、混同すると消耗する。

映画『サマーウォーズ』に象徴的な描写がある[3]。主人公の健二が、深夜に届いた巨大な桁数の数字列を、紙とペンで一晩かけて解読しようとする場面だ。ドラマとしては成立している。だが現実の人間が、この種の公開鍵暗号を手計算で解くのは事実上不可能だ。計算量の壁は、意志や集中力で越えるものではない。

個人開発でも、同じ手触りの壁は身近にある。たとえば毎フレーム数百万頂点のメッシュをCPU側で変形させようとして、メモリ帯域やVRAMの物理上限に張りつく場面。アルゴリズムをいくら磨いても、データの転送量という外部制約が天井になる。これは「難しいだけ」ではなく「設計を変えるサイン」だ。O(n²)の処理をn=10万で回そうとして詰まるのも同じで、「もっと頑張れば動く」と信じて最適化に時間を溶かすのは、本物の限界を「難しいだけ」と誤読した結果だ。

「難しいだけ」は、手順を分解して学習を積めば越えられる壁だ。「物理的に不可能」は、制約が自分の外側にある壁で、分解を深める方向ではなく、制約の回避か設計変更が要る。

「できない」を疑う姿勢は大事だが、同じくらい「これは本当に越えられない壁か？」と問い返す必要もある。

楽観は武器だが、キャリブレートされていない楽観は方向を誤らせる。

5. それでも「難しいだけ」は攻略できる ── 観察し続ける習慣

§4で見た「規模の壁＝多くは難しいだけ」を、どう越えるか。ここでもフリーレンの行動様式が参考になる。ただし鍵は一度の天才的なひらめきではなく、習慣のほうにある。

フリーレンは千年のあいだ「未知の魔法を集め、構造を読み解き続ける」ことを旅の動機にしてきたキャラクターだ。新しい魔法を見れば観察し、記録し、なぜそう働くのかを読み解く。この地道な積み重ねが、開発の学習サイクルとそのまま重なる。ドキュメントを読んで終わりにせず、実際に動かして挙動を観察し、「なぜこう動くのか」を仮説として立て、別のケースで確かめる。観察してログを取り、構造を読み解く——この反復で少しずつメンタルモデルが精緻になり、「なんとなく動いている」が「こうだから動いている」に変わる。その変化こそ「イメージできる」状態への接近だ。

その習慣が頂点に達した例が、黄金郷のマハト編（単行本9〜11巻）だ。ざっくり言うと、人類には解除不能とされてきた呪い《ディーアゴルゼ》——触れたものを黄金に変えてしまう魔法——にフリーレンが挑む話だ。フリーレンは作中で一度この魔法を自ら受け、身をもって観測したうえで、自分にかかったそれを解除している。そのとき得た観測と経験が、術者マハトの記憶の解析と噛み合い、「解除不能」とされた呪いを攻略可能な魔法へ組み替える鍵になった。長年の観察習慣に、過去に自分で踏んで得た経験が積み重なって、「誰も攻略できない」壁に手がかりが生まれたわけだ[4]。

ここにもうひとつの示唆がある。一度自分の手で踏んで観察した経験は、その場で消えず、次のもっと手強い壁で効いてくる資本になる。開発でも、過去に一度「なぜこうなるのか」まで腹落ちさせて解いた詰まりは、別の場面の似た問題であっさり効く。観察は、その場かぎりの理解ではなく、将来使える経験として積み上がっていくものだ。

ここで言う「観察」は、闇雲な試行錯誤とは違う。やみくもに当てずっぽうを繰り返すのではなく、構造の理解を狙って動かし、結果を読む行為だ（§6で触れる「最小実験」も、この意味での観察を指す。手当たり次第に試すことではない）。相手の手の内を正確に理解することで、「不可知」を「可知」に変える。それが「難しいだけ」の壁を削っていく王道になる。

6. 個人開発者への落とし込み

抽象論で終わらせない。「イメージを広げる」を具体的な手順に落とす。

① 分解する：「Flutterでリアルタイム同期する」ではなく「FlutterからFirestoreへのStreamを張り、UIをStreamBuilderで購読し、競合をトランザクションで解決する」まで展開する。一文で言えない工程は、まだイメージがない部分が残っている。

② 部品を学ぶ：分解したステップのうち「言葉は知っているが手順が浮かばない」部品を特定し、そこだけを動く最小コードで確かめる。全体を動かす前に部品を動かす。

③ 観察して精緻化する：動かしてログを取り、「こう動くはず」と実際の挙動を比べる。ずれた箇所が「イメージが甘かった部分」の座標だ。これは§5でフリーレンがやっていた観察と同じで、当てずっぽうの試行錯誤ではなく構造の理解を狙った確認だ。修正するたびにメンタルモデルが更新される。

④ 抽象化とAIで借りる（借り物の限界を知りながら）：ライブラリやAI生成コードは積極的に使う。ただし「これは借り物のイメージだ」と意識し、自分がまだ理解していない境界を把握しておく。その境界が次の学習対象になる。

「難しい」と「不可能」の見分け方：これは詰まってから判定するより、着手前に効かせたい。まず外部制約——計算量・物理量（メモリ帯域やストレージ）・ライセンス——の「桁」を概算する。次に「数時間で答えが出る最小実験を作れるか」を問う。作れて、しかもドキュメントか実装例か観察で確かめられるステップに行き着くなら「難しいだけ」だ。逆に、概算の段階で物理法則・計算量の絶壁・ライセンス上の禁止に突き当たるなら「不可能」で、その先は分解ではなく設計変更の領域になる。着手前に「どちらか」を測る習慣が、無駄な消耗を防ぐ。

ここまで偉そうに書いてきたが、私自身がこの「イメージできない→できる」を15年かけて地で行った人間だ。

プログラミングという言葉を知った小学生のころ、コードは得体の知れない文字列の塊で、自分が理解できる日が来るとは思えなかった。中学で教材をなぞっても氷山の一角、高校でゲームを作れるようになっても、オブジェクト指向や設計手法が次々と湧いてくる。大学で設計や可読性を求められても、一人前になれるイメージは最後まで持てなかった。

それが社会人になり、実務で点と点がつながった。「なぜこう作るのか」がメモリの動きまで含めて腑に落ちたとき、初めて全体を最後まで再生できるようになった。今は生成AIも使いながら、たいていのものを分解して言葉にできる。つまり、イメージできる。

15年前に「無理だ」と感じた壁は、不可能だったのではない。ただ、イメージが追いついていなかっただけだ。

まとめ

「できない」の多くは「まだイメージできていないだけ」だ。イメージとは完成までの手順を頭の中で再生できる状態であり、個人開発では「実行可能なステップに分解できている」ことと等しい。

我々が普段使っているものの多くは「借り物のイメージ」の上にある。AIも例外ではない。新しいものを作るとは、その借り物が終わる地点から先を自分のイメージで埋めていく作業だ。

楽観は大事だが、キャリブレートされていない楽観は壁の種類を誤読させる。「難しいだけ」と「物理的に不可能」を見分け、難しいだけなら分解・学習・観察のサイクルで攻略する。挑戦マインドとは「なんでも信じれば叶う」ではない。イメージを広げ続ける意志を持ちながら、限界の座標も正確に測り続けることだ。

あなたが最近「できない」と感じた場面は、どちらだっただろう。本物の壁だったか、それとも「まだイメージできていないだけ」だったか。

最後に、少し蛇足を。

サマーウォーズの健二は、常人なら匙を投げる難問に、紙とペンで食らいついた。あれはフィクションだし、計算量や物理の壁が現実に消えるわけでもない（§4で見たとおりだ）。それでも、食らいついていくその姿勢は本物だ。そして『葬送のフリーレン』の戦士アイゼンは、「素手でダイヤモンドを砕くようなものだ」と評された壁を、平然と「できる」と言い切り、勇者ヒンメルもそれに続いた[5]。

世間が「現代では無理だ」と決めつける難問の多くは、本当は誰かが「できる」のかもしれない。そしてその誰かは、生まれつきの魔法使いではない。イメージを広げ、手を動かし続けてきた——発想と努力の塊だ。

それはもしかしたら、あなたかもしれない。

参考・出典

[1] 山田鐘人・アベツカサ『葬送のフリーレン』（小学館）。作中の魔法観を表す台詞を引用。

[2] 山田鐘人・アベツカサ『葬送のフリーレン』第45話（単行本5巻収録、小学館）。フリーレンの台詞「水を操る魔法使いに雨の中で勝てるイメージが出来る？」を引用。

[3] 細田守（監督）『サマーウォーズ』（マッドハウス、2009年）。健二が暗号を手計算で解読しようとする描写を参照。

[4] 山田鐘人・アベツカサ『葬送のフリーレン』9〜11巻・黄金郷のマハト編（小学館、2022〜2023年）。

[5] 山田鐘人・アベツカサ『葬送のフリーレン』（小学館）。アイゼンとヒンメルが「素手でダイヤモンドを砕くようなものだ」と評された行為を「できる」と返す場面を参照。

宣伝

Xアカウント：@mryocode123

普段はこんなものを作っています：

コピペを題材にしたインクリメンタルゲーム
なろう小説をマッチングアプリ式に探索できるアプリ
素数ガチャ（超大桁の素数をガチャで引いて、新発見かどうかを判定する謎アプリ）

リリースしたら、ぜひ遊んでください！
開発の進捗は X（@mryocode123）で発信しているので、よかったらフォローしてもらえると嬉しいです。

Qiitaもフォローお願いします

この Qiita では、今後も実体験にもとづいた開発者のリアルな情報を発信していく予定です。
「実際に使って効いたテクニック」を中心に、個人開発での生きた知見をシェアしていきます。
役に立ったら、フォローやこの記事へのいいねが次の記事の励みになります！