設計は完了し、計画も立て終え、いよいよコードを書き始める段階になった。しかし、AIツールが存在する今、「コードを書く」という作業は、以前の手法とは大きく異なっている。この記事では、私がどのように技術を選定し、自然言語処理ツールを活用してコードのナビゲーションや編集を行い、計画に沿って段階的に進めていったか、その実際の体験について述べる。
技術選定：なぜこれらなのか
仕様策定の段階で技術スタックはすでに決定していましたが、ここでは選択理由を簡単に説明します：
Next.js App Router：Server Components によりデータの読み込みがクリーンになり、クライアントとサーバーの間でデータをやり取りする必要がなくなります。また、App Router のネスト構造は、このサイトの構造（公開ページと管理バックエンドが外層を共有するが、内層は完全に異なる）に非常に適しています。
Prisma ORM：型安全なデータベース操作が可能で、スキーマがドキュメントそのものとなります。マイグレーションの管理も、手書きのSQLよりも信頼性が高いです。
3言語対応のi18n：translation groupモデルを採用——各コンテンツにはtranslationGroupIdが割り当てられ、同じグループのzh-TW、en、jaのレコードはこのIDを通じて関連付けられます。これは翻訳をJSONフィールドに埋め込むよりも柔軟で、検索も容易です。
pCloud 画像ストレージ：画像をデータベースから外部ストレージに移し、DBの肥大化を防ぐ。pCloudのAPIはシンプルで、アップロード後に取得したURLをそのまま使用できる。
Serena MCP：コードを理解してから手を動かす
このプロジェクトで私が最も感銘を受けたツールの一つがSerena MCPです。これはセマンティックなコードナビゲーションツールであり、一般的なテキスト検索とは異なり、コードの構造を理解します。
例えば、「Articleモデルがどこで参照されているか」を知りたい場合、grepで文字列を検索すると、無関係な結果が大量にヒットする可能性があります。しかし、Serenaのfind_referencing_symbolsを使えば、どの関数やコンポーネントがこのモデルを実際に使用しているかを正確に把握できます。
私が最もよく使う機能は以下の通りです：
get_symbols_overview：ファイル内にどのような関数、クラス、インターフェースが含まれているかを確認できます。ファイル全体を読み込むことなく構造を把握できます
find_symbol：nameやpathを使って特定の関数や型定義を検索します。例えば、ArticleEditor/handleSaveなど
replace_symbol_body：特定の関数の実装部分を正確に置換し、ファイル内の他の部分には影響を与えません
insert_after_symbol：特定の関数の後に新しいコードを挿入し、ファイル構造の整合性を維持します
これらの操作に共通するのは、いずれも「コードのセマンティック単位」を対象としており、「行数」単位ではないという点です。これにより、コード修正の精度が大幅に向上し、「Aを修正してBを壊す」リスクも大幅に低減されます。
execute-plan：リストに従って実行
planが作成された後、実装段階ではexecute-planスキルが使用されます。その動作は非常にシンプルです。planファイル内のタスクリストを読み込み、一つずつ実行し、完了したタスクにチェックマークを付けていきます。
各タスクには通常、以下の要素が含まれます：
作成または変更するファイルのパス
具体的なコードの内容
完了後に実行すべきテストや検証コマンド
このプロセスの利点は、作業のリズムが保たれることです。プランにすべてが明記されているため、「これを終えたら次に何をすればいいのか」という迷いが生じません。タスクを1つ完了するごとにコミットを行うため、git logで振り返ると、明確な進捗の軌跡が確認できます。
pCloudへの移行：実践例
具体的な実装事例を挙げます。当初、画像はデータベース内に（Base64形式で）保存されていましたが、写真作品が増えるにつれ、DBのサイズが問題になり始めました。
この作業はプランの中で以下のステップに分解されました：
pCloud APIクライアントの作成
アップロードアクションを修正し、pCloudへのアップロード後にURLを保存するように変更
既存の画像を pCloud へ移行するためのワンタイムの移行スクリプトを作成
古いImageモデルと関連するAPIルートを削除
各ステップは独立して検証可能です。pCloudクライアントが完成すれば、移行全体が完了するのを待たずに、アップロード機能を単独でテストできます。この分割方法により、大規模なリファクタリングもそれほど恐ろしいものではなくなります。
コードの書き方が変わった
振り返ってみると、これらのツールを導入して以来、コードの書き方は確かに変わりました。以前はファイルを開いて最初から最後まで読み込み、修正後に「壊れていないことを祈る」だけでした。現在は、Serenaで構造を把握し、planで方向性を確認し、正確なセマンティック操作で修正を行い、完了後には明確な検証手順があります。
ツールがすべてのコードを書いてくれるわけではありません——技術的な意思決定や設計判断は依然として自分次第です。しかし、これらのツールは確かに「アイデアをコードに変える」というプロセスを、より体系的で予測可能なものにしています。
次回は、開発プロセスをよりスムーズにする補助ツールについて解説します。RTKがどのようにトークンを節約してくれるか、context7がどのように最新のドキュメントを検索できるようにしてくれるか、そして自動翻訳システムがどのように機能するかについてお話しします。