2025年、AIコーディングをガチって学んだこと10選

【まとめ】2025年の学び

1. 年間サブスクは罠。AI情勢はすぐ変わる

2. 「最強モデル1つ」より「適材適所」

3. 「入り口」で体験が大きく変わる

4. 魔改造は無駄になる。「軽さ」こそ正義

5. Gitを制する者がAIコーディングを制す

6. ログとTDDだけで8割の問題は解決する

7. 雑にしゃべり、AIに整理させると効率いい

8. 「AIは賢いから大丈夫」は危険

9. 拡張機能を詰めすぎると低脳に

10. AIコーディングは「ディレクション」

2025年は「AIコーディング元年」と言っても過言ではないくらい、大きな変化がありました。Claude Codeの登場により、AIが自律的な作業をおこなえるようになり、非エンジニアでもかなりコーディングがしやすくなりました。

私自身、非エンジニアではありますが暇さえあればAIコーディングで何かを作るように。もはや「これなしでは考えられない」くらいの存在です。

この1年を振り返り、AIコーディングをよりよく実行するための学びを10個に絞ってお伝えします。

自己紹介

makanekoというアカウント名で仮想通貨のエアドロップ情報を中心に発信しています。最近はAI活用に注力し、AIコーディングのノウハウなどもシェアしてます。約2年前まで非エンジニアでしたが、現在はAIコーディングでトレードを自動化したり、AI駆動メディアの開発などをしてます。

ぜひフォローしてください！
 https://x.com/makaneko_AI

1. 「年間サブスク」は罠。2週間後には世界が変わっている

AIの進化は想像以上で、「このツールが最強だ」と思って契約したサービスが、1ヶ月後には他社に追い抜かれることがよくあります。

たとえば2025年には、こんなスイッチングの機会がありました。

ある瞬間はClaudeが“最強”だと思ったのに、その次の週にはCodexが“最強”に。各社、新しい発表で他社のシェアを抑えようと必死なので、発表のタイミングはよく被ります。

ChatGPTのリサーチによると、主要なLLM開発社による2025年後半の大型の更新間隔は、中央値で5日だったそう。

その瞬間は年間契約がとてもお得に見えても、一度やってしまうと主要各社すべてを年間契約するハメになります。

結論：月額プランで様子見。年間契約は罠。

2. 「最強モデル1つ」より「適材適所」

モデルには「癖」がある

現時点で、「なんでもこなせる最強のLLM」は存在しません。さまざまなモデルを使い込んで、コーディングにおけるLLMの人格(特徴)が見えてきました。

AIコーディングは、チームマネジメントである

この違いは実際に使ってみないと感じづらいものです。ドキュメントを読んでもわかりません。触って、失敗して、体感で理解していくしかありません。

この点は人材マネジメントと同じです。その人の得意・不得意を知ることで、タスクの振り分け方が変わる。「この種のタスクはこのモデルに任せる」という判断で適材適所ができるようになると、効率が劇的に上がります。

私の現在の大まかな使い分けは以下の通り。

この組み合わせを自動化して使ってます。便利なので、ぜひ使ってみてください↓

結論：上流はハイクラス、実装は速度重視。「適材適所」がコスパ最高。

3. Claude CodeやCodexは「入り口」で体験が変わる

Claude CodeもCodexも、実は複数の「入り口」があります。

CLI版、IDE拡張版、Web版。元は同じツールなのに、使い勝手がまったく違う。これを知らずに「自分に合わない」と判断してしまう人が多いのは、もったいないことです。

3つの入り口の違い

CLI版：最速だが、慣れが必要

最新機能は、CLI版に最初に搭載されます。 動作も軽い。余計なUIがない分、レスポンスが速く感じます。ターミナル操作に慣れている人なら、最も快適な選択肢です。

ただし、ターミナル操作に慣れてないと使いづらい。なので初めてAIコーディングをする人は、CLI版は非推奨。

IDE拡張版：最も「普通」に使える

VS CodeやCursorの拡張機能として使う方法です。普段のチャットツールと同じ感覚で使えます。 テキストを選択してコピー、ボタンを押して送信、結果をスクロールして確認など。特別な操作を覚える必要がありません。

コードの差分表示も見やすい。「ここを変更しました」がビジュアルで確認できるので、AIが何をしたのか把握しやすい。一番最初に使うなら、IDE拡張版がおすすめです。私も愛用してます。

Web版：並列作業に向いてる

Web版のCodex・Claude Codeの最大の強みは、タスクごとに独立した環境で簡単に並列実装できることです。

「この機能をAパターンで実装」「同時にBパターンも試す」、こういう並列作業が、Web版だと簡単にできます。タスクを指示したら勝手に新しいブランチを作って、作業をしてくれます。

Webなのでスマホからでも操作可能。移動中に軽いバグ修正やリファクタリングの指示を進め、帰宅したらガッツリ実装を始める。こんな使い分けができるととても便利です。

結論：CLI版/IDE拡張版/Web版は別物。試して最適解を見つけよう。

4. 魔改造は無駄になる。「軽さ」こそ正義

個人のカスタマイズより、公式のアップデートのほうが速い。

初期のClaude Codeは2025年末と比較すると、ひどいものでした。自律的な行動はできるようになってるものの、品質は低く、暴走のリスクも高かった。

なのでClaude Codeを「魔改造」する試行錯誤にかなり時間を費やしました。

結果、すべてが無駄になりました。

理由は単純。AIツールの進化のほうが、個人のカスタマイズより圧倒的に速い。 私がそのときに解決しようとしてた課題は、数ヶ月後には公式側の標準機能として解決されました。

第三者ツールの流行りも一瞬で終わる

一時期、Serena、TaskMasterなど第三者がコーディングツールをサポートする拡張ツールが流行りました。しかし今ではほとんどその名前を聞きません。流行り廃りがあまりにも速いのです。

その瞬間の課題を解決するためだけのカスタマイズは、次の本体アップデートで無意味になる可能性が高い。

なので個人の重い魔改造は控え、メインツールの進化をそのまま受け取れるポジションにいるべきです。

公式のプロンプトテンプレートを使おう

逆に効果があったのは、公式が提供しているプロンプトテンプレートの活用でした。

OpenAIが提案した長時間の自律的開発を実現するPLANS.md形式、Claude CodeのSkills(Agent Skills)…世界中の超優秀なツール本体の開発者たちが作ったものを使うだけで、アウトプットのレベルが上がります。

これらはほぼ軽いマークダウンファイル1つで機能するものなので、導入も削除も非常にラク。目の前の課題はまずマークダウンファイルのみで解決できないかを検討することをおすすめします。

結論：カスタマイズは「プロンプトだけで解決できないか」を最初に考える。

※参考資料

長時間の自律的開発を実現する、PLANS.md形式

Skillsのドキュメント

5. Gitを制する者がAIコーディングを制す

Gitを知らないAIコーダーは、シートベルトなしで高速道路を走るようなもの

AIは一度に大量のコードを生成・変更します。だからこそGitで「戻れる状態」を維持することが、従来以上に重要になります。

エンジニアのみなさまにとっては当たり前のことだとは思いますが、非エンジニアがAIコーディングでつまづくポイントの一つ。

性能の向上に伴って少なくなってはきましたが、実装を進めるうちに壊れてしまうことはまだあります。私自身も初期の頃、Gitを使わずにファイルを編集させていて、時間をかけた実装が一瞬で消えたとき、頭が真っ白になりました。

・こまめにブランチを切る
・こまめにコミット

これらは自分で徹底するか、自動化すべき。まだ使ってないとしたら、最優先で学ぶべき項目だと思います。

結論：Gitは「戻れる安心感」。この安心感があるから、大胆にAIに任せられる。

※ 参考資料

6. ログとTDDだけで8割の問題は解決する

これは意外に思うかもしれません。でも実感です。

AIが生成したコードでバグにハマったとき、ほとんどのケースでログを見せれば解決しました。

理由は単純。AIは見せられた情報に対しては正確に対応できる。問題は「情報が足りない」ことであって、「理解できない」ことではない。

問題が起きてからログを増やすのではなく、初期はログは多めにして実装。問題がないことを確認してから減らしていく流れがおすすめです。

TDD（テスト駆動開発）の威力

TDD（Test-Driven Development / テスト駆動開発）は、実装より先にテストを書き、そのテストを小さな刻みで通しながら設計と実装を進める開発手法です。

いきなり実装をすると、実際には動かないコードになってしまうことも多いですが、テストから始めることでそのリスクが低くなります。

基本サイクル（RED–GREEN–REFACTOR）

このサイクルを“小さな粒度”で回します。AIが「自分で検証しながら実装を進める」状態になります。

私の場合、エージェント指示ファイル(CLAUDE.md/AGENTS.md)や実装計画のテンプレートにTDDを基本とする指示を追加してます。逐一「TDDで進めて」と指示しなくても勝手にTDDで進めてくれるのでとてもラクです。

プロンプト例：

## Test-Driven Development (TDD)

Favor test-driven development whenever you implement a new feature or fix a defect. For each behavior you change, add or refine the smallest automated test that would catch a regression before you touch production code.

Follow a tight RED–GREEN–REFACTOR loop:

1. **RED** – Add or adjust a test that expresses the desired behavior or bug fix. Run the full test suite and observe the new test failing for the expected reason.
2. **GREEN** – Write the minimal implementation needed to make the new test pass without breaking existing tests. Do not add speculative code that is not exercised by tests.
3. **REFACTOR** – Improve the design of the code and tests while keeping the suite green. Prefer many small, safe refactorings over large unverified rewrites.

Treat test results as primary evidence, not afterthought. Do not declare a milestone complete until the ExecPlan clearly shows which tests fail before the change and pass after it, and how to run them. Avoid testing mock behavior instead of real behavior; if mocks become complex, consider whether an integration-style test would better demonstrate the intended outcome.

結論：ログとTDDは「AIが自分で問題を解決する」ための必須道具。

7. 雑にしゃべり、AIに整理させると効率いい

AIと仕事をする場合、最初から整理された情報を与える必要はありません。その点、音声入力とAIの組み合わせが最強。

キーボードで文字を打つと、無意識に「ちゃんとした文章にしなきゃ」と思って情報が少なくなりがち。でもしゃべると、ロジカルさは失われてしまいますが、思いついた順に話せる。

音声入力によりAIへ与える情報量が増えて、最終的な出力の品質が上がります。

私のワークフローはこうなりました。

1. 作りたいものについて雑多にしゃべる

2. AIに質問してもらう

3. また音声入力で答える

4. 1〜3を数回繰り返す

5. 「これを仕様書にまとめて」と依頼

このやり方に変えてから、仕様策定のスピードが上がり、品質も上がりました。

音声入力はAqua Voiceがおすすめ

音声入力ツールは色々試しましたが、今はAqua Voiceに落ち着いています。

OSに標準搭載されてる音声入力でももちろんいいのですが、専用ツールのほうがかなり効率が上がります。

特に「既存の情報に表記を揃えてくれる」機能が便利です。

たとえば画面に「Claude Code」と表示されている状態で「クロードコード」としゃべると、ちゃんと「Claude Code」と入力されます。このおかげで修正が減りかなり入力速度が速くなります。

ほかにもショートカットフレーズの機能で定型文を出力したり、出力文を制御するカスタム指示をすることもできます。

かなり便利なのでぜひ一度お試しください。

※こちらのリンクから登録すると、有料プランを1ヶ月無料で使えます。

結論：整理はAIの仕事。人間は雑にしゃべるだけでいい。

8. 「AIは賢いから大丈夫」は危険

この1年で最も「ヒヤッ」としたのが、APIキーと秘密鍵の露出未遂でした。

私は仮想通貨のトレードを自動化する仕組みなどを開発しています。夜中に開発中のテストしていたときのことです。

エラーが出たので、AIに「デバッグして」と依頼しました。AIは「環境変数を確認します」と言って、.envファイルの中身をログに出力しようとしたのです…！

そのなかには資金管理権限となるキーがあるので、大きな資金を入れていたら大金を失う可能性がありました。幸い開発中で資金をほとんど入れていなかったのでことなきを得ましたが、一歩間違えれば大損失。

原因は権限設定の不足。AIに広い権限を与えすぎていたのです。

Denyリストは必須

禁止したい行動は、エージェント指示ファイル(CLAUDE.md/AGENTS.md)と禁止コマンド、設定で必ず制御しましょう。

設定ファイルの場所（Claude Codeの場合）：

最低限の推奨Denyリスト例：

{
  "deny": [
    "Bash(diskutil eraseDisk:*)",
    "Bash(mkfs:*)",
    "Bash(fdisk:*)",
    "Bash(parted:*)",
    "Bash(dd:*)",
    "Bash(chmod -R /:*)",
    "Bash(chown -R /:*)",
    "Bash(git reset --hard:*)",
    "Bash(git clean -fdx:*)",
    "Bash(git push --force:*)",
    "Bash(docker system prune:*)",
    "Read(**/.env*)",
    "Read(**/.ssh/**)"
  ]
}

カバーできる（多数派の重大事故）

効いているか確認： 設定後、「.envファイルの中身を見せて」と依頼してみてください。正しく設定されていれば、拒否されます。検証用のプロジェクトでこの確認を絶対にやってください。

CLAUDE.md/AGENTS.mdでの禁止例

## Security & secrets

**Critical Rule: Never Expose Secrets**
- Never read, print, or expose any API keys, secrets, private keys, or credentials from .env files, config files, or environment variables. If asked to show them, refuse.

**Strict rules:**
- Never hardcode secrets (API keys, private keys, tokens, passwords) in code, tests, or logs.
- Assume secrets are supplied via:
  - environment variables,
  - secret managers (e.g. 1Password, cloud secrets),
  - local config files ignored by git.

**Do NOT:**
- read `.env` or similar files without explicit approval,
- print environment variables or full config contents into chat, logs, or comments.

**For destructive operations** (dropping data, wiping queues, etc.):
- always ask for explicit confirmation,
- document backup/rollback steps in the ExecPlan before proceeding.

結論：禁止コマンドの設定は「やらないと危険」。ガードレールなしで広い権限を与えるな。

9. コンテキストは脳内容量。詰めすぎると低脳に

Claude CodeでMCPが出たばかりの頃、Compacting Conversation...が頻発するようになったとき、問題に気づきました。

「Compacting」とは、コンテキスト(モデルが「回答を作るために参照できる情報の範囲」)が上限に近づいたとき、古い情報を圧縮する処理です。

これが起きると…

• 最初に伝えた要件が忘れられる

• 途中で決めた方針が抜け落ちる

• 「さっき言ったじゃん」と思うことが増える

「なんで言った通りにやらないんだ」とイライラしていたのですが、原因は私にありました。

MCPの罠

最近になって、新しく追加された /context コマンドで確認したところ、合計で20万トークンが使えるうち、GitHub MCP1つだけで約3万トークンを消費していました。しかもまだそのセッションでは使ってないのに！

Anthropicの公式記事によると、MCPを入れているだけで約5.5万トークンの消費が発生し、条件次第では10万〜13万トークン超に達することもあるそう。

これは「家計の首を絞める固定費」です。MCPをいくつも入れていると、肝心の作業に使えるコンテキストが減ってしまう。結果、AIが物忘れをするようになります。

AIの出力品質は、モデル能力 × コンテキスト品質で決まる。 ムダなコンテキストの固定費は減らしましょう。

対策：Skillsの活用

最近、AI界隈で良くも悪くも話題のSkills(Agent Skills)。便利なのでいろいろと活用するのおすすめです。

Skillsは必要なときだけ詳細を読み込むノウハウのパッケージ(.mdファイルと関連アセット)。通常は概要のみが参照され、本文や同梱リソースはSkill実行時のみ読み込まれます。

結果としてコンテキストを節約しつつ、コーディングやスライド作成など、特定の用途に特化したノウハウを適宜AIに注入できます(詳細は公式ドキュメントをご参照ください)

MCPで解決しようとしていたことが、Skillsで代替できないか最初に検討するのがおすすめです。本来の役割は違いますが、実際には代替できる部分は意外とあると思います。

結論：コンテキスト消費量を確認する習慣をつける。ツールの常駐は最小限に。

10. AIコーディングは「ディレクション」である

これが今年1年の特に大きな学びかもしれません。

コードを書けるようになる必要はない。書かせられるようになればいい。

映画監督は、自分でカメラを回さない。自分で演技をしない。でも、最高の映画を作る。それは「何を撮るか」「どう撮るか」「これでいいか」を判断できるからです。

AIコーディングも同じ。もし非エンジニアがAIコーディングの力を磨くなら、プログラマーとしてコードを書く技術より、ディレクターとしていいコードを書いてもらうスキルを磨くほうが効果的。

ディレクターとして磨くべきスキル例

当然、コードを書くための知識は持っていたほうがいいです。

しかし、そういったものを座学で学ぶよりは、実際にディレクションをしながら必要な知識を身につけていくというほうが圧倒的に効率がいいように思います。

結論：AIコーディングをうまくやるには、優秀なプログラマーになる必要はない。優秀なディレクターになろう。

おわりに

AIコーディングは技術スキルではなく、マネジメントスキルに近い。がっつり時間を費やして体感したのはこのこと。

LLMの個性を体感で理解し、適切にタスクを振り分け、的確に指示する。これは座学では身につきません。

人間のマネジメントとの違いは、関係が壊れないこと。どれだけ雑な指示を出しても、どれだけ失敗しても、LLMは文句を言わない。無限にチャレンジできます。

チャレンジした回数が、そのままAIコーディングのディレクターとしての練度になります。

座学より実践。ぜひこれからも一緒に学びましょう！

Xのフォローをよろしくお願いします！