ITエンジニアにとって、AI が一般化したが･･･
最近、日常のコーディングはもちろん、プライベートでの開発でもAI（特に Claude Code）を普通に使うようになりました。
普段の使い方としては、情報収集や技術的な質問・壁打ちには Gemini を使い、実際のコード生成には Claude（コマンドライン） をメインで活用しています。
Claude は本当に驚くほど便利なのですが、同時に「たまにびっくりするほど的外れでヘコい提案や実装」をしてくることもあります。そのため、その都度人間側で「軌道修正」を行う作業が欠かせません。
それでも、「動くコード」と「テストコード」をセットで書いてくれるため、一定レベルの「品質担保」が図れます。私のように「頭の中に設計やコードは浮かんでいるけれど、それを写経のようにキーボードでひたすら打ち込んでいく作業が辛い＝コード作成がもはや単なる作業」と感じている人間にとっては、非常に有効で便利です。さらに、claude.md に明確な制約やコーディング規約を書いておけば、適切に関数化や共通化を行ってくれるため、かなり良い感じで成果物が出来上がります。
ノーエンジニアがノーコード＝絵空事
ただ、実際にAIでコーディングをすればするほど、そして使えば使うほど痛感するのは、「ノーエンジニアがノーコードでプロジェクトを爆誕させられる」というのは、まさに『絵空事』だということです。
AI利用がある程度定着した中で冒頭の動画を見て、「いやあ、本当にその通りだな！」と強く共感したため掲載しました。今回私が書く記事の前提としても非常に参考になる内容だと感じたからです。
結局のところ、「ノーエンジニア・ノーコードでアプリ開発ができる」というのが絵空事である理由は、動画でも語られている通り『ドメイン知識』の重要性に帰結します。ドメイン知識とは「人間や組織が積み上げてきた成果物」そのものです。AIをあくまで「部下」という立ち位置として捉えると、「ノーコード・ノーエンジニアで開発する」ということは「重要なドメイン知識を自ら構築・理解できないまま、部下に丸投げしている状態」に他なりません。だからこそ、実現不可能な絵空事なのです。
AIでプログラマーが不要になるはずがない！！
昨今、一部の誇大広告的なYouTuberなどが「ノーエンジニア・ノーコード」を声高らかに叫び、「プログラマー不要論」を唱える動画が増えています。しかし、実際にAIを使ってコーディングを行っている現場から見れば、「プログラマーが不要になるどころか、プログラマーがAIを使ってプログラムを書くのが仕事になる」という未来しか見えません。
「プログラマーがAIを使ってプログラムを書く」ようになると、これまで「コードを書くこと」に使っていた時間が大幅に短縮され、その分「それ以外の作業」へ注力できるようになります。
これは、AWSの登場によって起きた変化と非常によく似ています。かつては専門のインフラチームが手動で行っていた「サーバーのセットアップやミドルウェアの導入・チューニング」といった作業が、クラウド化によって開発エンジニア自ら「Terraformなどを用いてインフラをコードで構築・管理する」スタイルへと移行しました。これと同じことが、開発領域でも起きているわけです。
実際のAI導入後の開発現場では、コード生成時間が短縮されたことでリリースサイクルが早まっています。その結果、「プログラムを書く時間は減ったのに、かえって忙しくなった」という現象も起きています。流石にAIでは良し悪しの判断が難しい 動作確認 や UX/UIの磨き込み など、人間が対応すべき領域が増えたためです。「少ない人数でプロジェクト開発ができるようになった（効率化された）」反面、エンジニアが短期間でマルチにカバーすべき範囲が広がり、結果として忙しくなっているのだと感じます。
一方で、AIによって一定のコード品質は保てる
逆に言えば、AIの利点として「個人のコーディング力による差」が平坦化され、誰が実行しても「一定レベルのコード品質」が得られるようになります。そのため、今後は単に「コーディング能力が高い人」よりも、「設計やコーディングルール、最適化に精通している人」や「コミュニケーション能力が高い人」の方が、AI時代におけるエンジニアとして伸びていく印象があります。
ただし、「AIにコードを丸投げする」のは厳禁です。提案型として提示させ、設計の方向性や修正箇所を「人間が確認しながら」進めないと、気づいた時には想定外の破壊的変更が加えられてしまうことがあります。そして後から連携が取れなくなった際に、AIがドヤ顔で「このようになっているので修正が必要です」といった的外れな対応をしてくる——これこそが「ヘコいAI対応」の典型です。これらを正しく理解し、適切に指示出しができる能力こそが、現代の「AIノウハウ」と言えます。
AIにゴーストは宿らない！！
少し『攻殻機動隊』のような話になりますが、まさに「AIにゴーストは宿らない」のです。『攻殻機動隊』の制作者たちは、このAI時代の未来を予測していたのかと思うほどです。
要するに、AIはあくまで「学習データに基づいて処理された情報を確率的に計算し、受動的に1文字ずつ出力している存在」に過ぎません。人間のように自然な回答ができることには感心しますが、言い換えれば「AIは自発的に思考することができない＝ゴーストは宿らない」のです。
また構造上、AIは「自身のコンテキスト（メモリ）内に情報が存在しなければ、内容を正しく解釈できない」という仕組みになっています。たとえば claude.md などの情報も、チャットで指示を出すたびに毎回裏で送信されており、過去のコンテキスト情報の範囲内でしか解釈を行っていません。この仕組みである以上、そこに意志（ゴースト）が宿ることはあり得ないわけです。
だからこそ、「AIに何をしてほしいか」を巧みに伝える「AI技術・ノウハウ」や、前提条件としての claude.md の記述、そしてそこに「ドメイン知識」を正しく植え付ける作業が必要です。そうすることで初めて、AIが「あたかも自発的に動いているかのような精度」で実行してくれる——これこそが、２０２６年現在における正しいAIの使い方なのだと思います。
２０２６年になって作った個人プロジェクト
私が本格的にAI開発へとシフトしたきっかけは、会社の業務ではなく「個人プロジェクト」でした。約半年前から少しずつ取り組んできた中で得られた、AI開発の実践的なノウハウをご紹介します。
まず、2026年に入って2番目に作成した個人プロジェクトです。一部の手動修正を除き、ほぼノーコード（Claude を本格的に活用）で構築しました。
次に、「元々手動でコーディングしていた既存コード」に対し、後から claude.md を追加して Claude で仕上げたプロジェクトが以下の2つです。
一番最初に作ったのは「PC98版のマイトアンドマジック的な3D RPG」をブラウザ実行できるもの
当初は「Claude コマンド」や「ローカル環境での実行」に対して少し危険な印象を持っていたため、ブラウザのチャットUI越しに Claude Code へ指示を出してコーディングさせていました。今思えば非常に非効率なアプローチだったと思います。
ただ、AIの「頼りなさ（ヘコさ）」を痛感するには良い経験でした。ブラウザチャット上で Sonnet などのモデルを使い、少し規模の大きいプログラムを書かせようとすると、途端に場当たり的な提案やハルシネーション（誤情報）を連発するようになります。
さらに、場当たり的なコード生成を重ねた結果、コード全体がスパゲッティ化し、AI自身が何度修正しても直せない「新たなバグの製造装置」と化してしまいます。無駄にトークンを消費し、時間を浪費するだけの「モンスター」へ成り下がってしまうのです。
この経験から、「途中で人間がすべてのコードを読み解き、共通化されていない部分を整理して、AIに設計のルールを周知し直す必要性」を深く実感できました。最初から「Claude コマンドを使い claude.md にテンプレートを書く」のとはまた違った角度から理解が深まったため、最初はあえてブラウザチャット経由で大きめの開発を試してみるのも、AIコーディングの特性を理解する上で良いステップになるかもしれません。
社内プロジェクトで、OpenAIを使って社内文書をRAG化する仕組みを作った
AIに注目した初期のきっかけは、「社内ドキュメントをRAG（検索増強生成）化すれば、作成されたまま放置されている大量の文書を利活用できるのではないか？」と言うことで、社内RAG化プロジェクトに参加して、関わった事がきっかけでした。そこで「具体的にどのような仕組みでAIが文書をRAG化するのか」に興味を持ち、調べながら手動でプログラムを書いて作ったのが以下のプロジェクトです。
現在は Claude によるAIコーディングを用いて動作する形に仕上げていますが、元々は自前で組み込みモデルを用いてベクトル座標を計算し、簡易的なベクトルDBもどきを作成しました。そこに「近似値の検索条件＋推論モデルで作成した文書サマリー」をAIに渡してRAG化する仕組みです。
実際にローカルLLMサーバーを用意して動かしてみたところ、それなりにRAGとして機能したものの、返却フォーマットに揺らぎが出るなど課題も見えました。しかし、この開発を通じて「AIに渡すプロンプトの構造と役割」に対する理解を大きく深めることができました。
VJAというローカルLLMでコード生成する開発ツールを作ってみた
（起動画面）
（フォームにウィジェットを配置した例）
（コードの代わりに yamlでAIに指示を出す例）
（AIが生成したコード例）
（VJAアプリ実行例）
VJA (Visual Js for AI) は、かつてMicrosoftが提供していた「Visual Basic 6 (VB6)」の開発手法を踏襲して考案したツールです。私自身、Windows 95時代に初めてアプリを作成した際の感動が記憶に残っており、このイベント駆動型のアプローチが「ローカルLLM環境に非常にマッチするのではないか」と考えたのがきっかけでした。
ローカルLLMはクラウドAIと異なり、リソースの制約を受けます。私自身、DDR5メモリ64GBにRyzen AI搭載のミニPCを用意し（Ubuntu + Vulkan + llama.cpp の軽量構成）、ローカルLLMサーバーを構築しました。20万円以上かけた構成ですが、それでもクラウドAIに比べると処理速度は遥かに遅く、単純な費用対効果だけで見れば「Claude CodeやOpenAIを使えば良い」という結論になってしまいます。
しかし、「AIの内部構造を理解する」ためには実機での検証が不可欠でした（半ばガジェット的な物欲もありましたが）。せっかく購入した環境を活かすため、「個人で管理するデータは限られているためRAGよりも、ローカルLLMを活用したローカルアプリ開発環境を作れないか？」と考えて生まれたのが VJA です。
VJAの構成と動作環境について
なぜVB6のアプローチがローカルLLMに最適なのかというと、VB6は「イベントに対して実行コードが紐付く」構造をしており、コード同士の依存関係が非常に小さく、画面中心の短いコードで実装できるからです。「コンテキストが小さく、独立した短いソースコードを生成する」タスクは、ローカルLLMが得意とする領域と合致しています。
また、Mac（Apple Silicon）であれば搭載されているNPU/Unified Memoryを活用することで、低電力かつ高速にローカルLLMを駆動できます。これを利用すれば「ローカルアプリをノーコード感覚で作れる環境」が実現できると考え、開発を進めました。
技術スタックとしては Bun.js および Electrobun を採用し、データベースには SQLite3 を使用しています。この構成をベースに、Claude（当初はブラウザチャット）を使って開発ツール自体を構築していきました。
ローカルLLMにおけるプロンプトのシビアな現実
ローカルLLMを運用する中で直面した最もシビアな現実は、「システムプロンプトとユーザープロンプトを明確に分離しなければならない」という点でした。
当初はユーザープロンプト側にすべての条件を詰め込んで送信していたのですが、日本語で2万文字近くになると、ローカルLLMが毎回のトークンを読み込んで処理（Prefill）するのに膨大な時間がかかってしまいます。対策を調べたところ、「静的なプロンプト（システムプロンプト）として分離することで、2回目以降の処理がキャッシュ化される」ことが分かったため、構成を分離しました。
分離により速度は向上したものの、絶対的なトークン数が多すぎるため、コード生成自体の待ち時間は剧的には改善されませんでした。そこで次の施策として、プロンプトを基本的にすべて「英語」に変換しました。英語化によってトークン効率が劇的に改善し、最終的には「1分以内にプログラムを生成できる」レベルまで高速化に成功しました。不要なコンテキストを限界まで削ぎ落とすチューニングも効果的でした。
ローカルLLMは「新しいモデル＝正義」ではない（ベンチマークの罠）
ローカルLLMのモデル選定においても重要な気づきがありました。近年の推論モデル（Gemma 4、Qwen 3.5、Qwen 3.6 など）は、旧世代に比べてコーディング能力が飛躍的に向上しています。しかしその反面、「推論（思考）のための時間が必要」となり、逆に推論モードをOFFにすると極端に性能が落ちるという特性があります。
当初、llama.cpp のブラウザUIから「テトリスを作って」と大まかな指示を出した際には、3分ほどで動くコードが出力されたため、「Qwen 3.5 4B あたりがVJAに最適だろう」と考えていました。
しかし、VJAのように約2万文字の静的コンテキストを与えた状態で10行程度の短いコード生成を指示すると、AIは推論のために2,000トークン以上を無駄に処理し、実行時間が5分を超えてしまう現象が発生しました。原因を調べた結果、処理時間の大部分が「プロンプトに対する推論トークンの生成時間」に使われていることが判明しました。かといって推論モードをOFFにすると、文脈を解釈できず動かないコードが出力されてしまいます。
そこで、Geminiの提案を参考に Qwen 2.5 Coder 7B を試したところ、わずか20秒程度で非常に正確なコードが返ってくるようになりました。
この経験から、コード生成のような明確なタスクにおいては、下手に新しい推論モデルを使うよりも、2025年世代のような「推論を挟まないコード特化型モデル（Qwen 2.5 Coder 7B や DeepSeek V2 Coder Lite など）」の方が遥かに高速かつ正確であることが分かりました。「最新モデル＝最高」とは限らないという良い学びになりました。
このVJAという環境は、現在 M1 Mac 等でも快適に動作し、AIを使ってノーコードに近い感覚でアプリ開発を行えるツールとして、Claude Code を使い約1ヶ月で完成させました。まさに「AIの恩恵」を実感できる成果物の一つです。
実は「手動で書き始めたソースコード」の方が AI開発に最適なのか？
次に取り組んだのが、冒頭でも触れた以下の2つの個人プロジェクトです。
元々 minto は、超軽量な AWS Lambda ランタイムである「LLRT」を活用して動かす超軽量フレームワークとして作成したものでした。一通り動くものができた段階で満足し、半ばお蔵入りになっていたプロジェクトです。
頭の中には追加の構想があったものの、他業務の優先度が高く後回しになっていました。しかし、VJAの開発で作成した claude.md のノウハウがあったため、その設定を流用して Claude コマンドで開発を再開してみることにしました。
隙間時間にコマンドで指示を出し、出力結果を確認しながら進めたところ、課題だった「ログイン認証周り」や「安価なS3 Table機能の対応」、さらに「ローカル開発用の代替S3/SQSサーバー機能」といった実践的な機能を、わずか2週間ほどで一気に実装することができました。
ここで得られた重要な気づきは、「人間が一度骨組みを書き、動作環境を整えたコードに対して Claude に後追いで機能を追加させた方が、完全にゼロから生成させるよりもコードの精度や美しさ（シンプル化・共通化）が遥かに高くなる」ということです。人間が書いた読みやすいコードのニュアンスをAIが踏襲してくれるため、VJAのようにゼロから作らせたものよりも綺麗な成果物が得られました。
AI開発は、過去に頓挫・お蔵入りしたプロジェクトの掘り起こしに最適
同様に glint についても、元々は「AIがRAGの回答を出す仕組み」を理解するために始めた実験的コードでした。これを minto と同じ手法で Claude に渡し、Webアプリ化や「SQLite3によるベクトル情報管理への変更」などを追加・改修させたところ、最終的に「サーバー起動＋ブラウザで使える個人用RAGツール」として完璧に完結させることができました。
「過去に発想はあったものの時間が足りず頓挫してしまったプロジェクト」に対し、claude.md を配置して Claude に続きやリファクタリングを指示する——この「過去資産の掘り起こし」こそが、AIコーディングにおける極めて効果的な活用パターンだと感じています。
まとめ：２０２６年におけるAIコーディングのリアルと活用術
(※ この内容はgeminiにまとめてもらいました)
今回、個人プロジェクトや日々の開発でAI（Claude Code、Gemini、ローカルLLMなど）を本格的に使い倒したことで、2026年現在の「実践的なAI活用」における明確な結論が得られました。
世間で囁かれる「ノーエンジニア・ノーコードでアプリ爆誕」や「プログラマー不要論」は、現場目線で見れば完全に絵空事です。AIに自発的な意志（ゴースト）はなく、あくまでコンテキストに基づいて文字を出力する「受動的な部下」に過ぎません。ドメイン知識や設計思想を持たない人間が丸投げすれば、場当たり的なコードとバグを量産するモンスターを生むだけです。
2026年現在、AIを使って開発効率を最大化するためのポイントは以下の通りです。
- 役割の明確化： AIは指示通りにコードを書く「優秀な打鍵要員（部下）」。人間は設計、方針決定、手綱引きを行う「指揮官（上司）」
-
コンテキストと制約の与え方：
claude.mdやシステムプロンプトを活用し、ドメイン知識や共通化ルールを明確にAIへ植え付ける -
プロンプトとモデル選定の最適化： 冗長なプロンプトは避け、必要に応じて英語化・軽量化を図る。また、最新の推論モデルに固執せず、タスクに応じて
Qwen2.5-Coderのような推論なしの高速・高精度なモデルを見極めて使い分ける - 既存コード・過去資産の掘り起こし： AIはゼロからの生成よりも、人間がベースを作ったコードや、過去に頓挫したプロジェクトの拡張・リファクタリングで真価を発揮する
AWSの登場でインフラ構築の作業スタイルが変化したのと同様に、プログラマーの仕事も「手動でコードを打ち込む作業」から「AIを制御して素早くプロダクトを形にする作業」へとシフトしました。
コーディングという「作業」の価値が平坦化された今、エンジニアに求められているのは「設計力」「ドメイン知識」「最適化のノウハウ」、そして「AIに的確な指示を出し、手綱を握るコミュニケーション能力」です。AIを正しく従え、自らの手でプロダクトをコントロールしていくことこそが、これからの時代における最強の効率化と言えます。
ー 以上 ー