嗜好化するToDo管理 — あとがき：開発環境の変遷とAIとの付き合い方

こんにちは、パレイド思想部です。

連載20回とデモサイト公開で「嗜好化するToDo管理」は一区切りつきましたが、書き切れなかったことがあります。HigherSelfの開発中に経験した開発環境の変遷と、コードだけでなく記事執筆にAIを使った試行錯誤です。あとがきとして記録しておきます。

コーディング環境の変遷
記事執筆にAIを使った苦労
学びのまとめ
次の挑戦へ

コーディング環境の変遷

ChatGPT + Python（初期）

HigherSelfの開発はChatGPTとの対話から始まりました。チャット上でPythonコードを生成し、手元のMacで実行する。プロトタイピングとしては速かったものの、プロジェクトが大きくなるとチャットウィンドウに収まらなくなり、ファイル間の整合性を人間が管理する必要がありました。

VS Code + GitHub Copilot

次にVS Codeでの開発に移行し、GitHub Copilotを導入しました。エディタ内でコードが生成されるため、プロジェクト全体を見ながら作業できるようになりました。

しかしこの時期、バックエンドにChatGPT 4.1を使っていたところ、ハルシネーションに悩まされました。存在しない関数やAPIを自信満々に提案してくる。Claude Sonnetに切り替えたところ、かなり改善しました。コードの正確性と、既存コードの文脈理解力に明確な差がありました。

Cursor

その後Cursorに移行しました。エディタ統合のAI機能が充実しており、開発体験は向上しました。ただし、結局ほぼClaudeしか使わなくなり、課金枠が厳しくなりました。Claudeの品質に依存すればするほど、消費量が増える構造です。

Claude Code + VS Code（現在）

最終的にClaude Code + VS Codeの組み合わせに落ち着きました。安定して動作し、プロジェクト全体のコンテキストを保持したままコード生成ができます。現時点で最も生産性が高い構成です。

ローカルLLMの試み

コスト削減を目指して、Continue + OllamaなどのローカルLLM構成も試しました。しかし、コーディング用途では実用が厳しいのが現状です。Qwen や gpt-oss が今後どこまで改善するかは注目していますが、現時点ではクラウドLLMとの品質差が大きすぎます。

記事執筆にAIを使った苦労

HigherSelfの開発中、もう一つ大きな挑戦がありました。コーディングに集中するため、開発記録や思想の言語化をAIに任せるという試みです。

ローカルLLMでの記事生成

最初はローカルLLMで記事を書かせようとしました。日本語の品質という観点ではGemmaが有力でしたが、12Bモデルでも文章の一貫性や論理展開が厳しい。gpt-ossに切り替えたらかなり改善しましたが、手元の環境では推論速度が遅く、試行錯誤のサイクルが回しにくい状態でした。

ChatGPT Atlasでの運用

クラウドに切り替え、ChatGPT Atlasで記事生成を運用しました。品質は安定しましたが、別の問題が出てきました。

WordPressの編集性がネックです。ブラウザ上のGutenbergエディタでの編集は、Markdownに慣れた身には辛い。そしてChatGPTは今見えているページしか参照できないため、連載全体の文脈を踏まえた記事が書けません。ハルシネーションも多く、過去の記事の内容を正確に引用してくれない。

プロジェクト全体を見せる

転機になったのは、VS Codeなどの開発環境でプロジェクト全体のファイルをAIに見せるようにしたことです。過去記事のMarkdownファイル、連載の構成計画、シリーズのメタデータ——これらが一つのワークスペースに存在すれば、AIは文脈を正確に参照できます。

CursorやAntigravityでも同様のアプローチが可能で、プロジェクト全体がコンテキストに入ることで記事の品質が明確に向上しました。

学びのまとめ

コーディングと記事執筆、どちらにも共通する教訓がありました。

AIにはコンテキストが必要: チャットウィンドウやブラウザ上の1ページだけでは足りない。プロジェクト全体を見せることで品質が劇的に変わる
環境は頻繁に変わる: 半年の間にChatGPT → Copilot → Cursor → Claude Codeと4回乗り換えた。ツールへの執着より、移行しやすい構成が重要
ローカルLLMは発展途上: コスト面の魅力はあるが、現時点ではコーディングにも記事生成にも品質が足りない。ただし進化は速い