近況の更新

2026-02-24

フリーランスの Web 系バックエンドエンジニアとして長らく現場での開発に専念していたが、 2025年12月末で一旦契約を区切り、直近の2ヶ月間は技術のキャッチアップ期間としてまとまった学習時間を設けた。

特にここ最近は AI エージェントを活用した開発スタイルの習得がエンジニアとして生き残る上で不可欠だと感じており、危機感を募らせていたのもあり、この期間の学習テーマの一つとした。

この投稿では、2ヶ月間で取り組んだ内容を時系列順にまとめる。

2026年1月前半: 開発環境の刷新と AI エージェントの検証

開発環境のアップデート

個人的な開発では自作 PC とノート PC を使用していた。しかし自作 PC で使っている OS (Kubuntu 21.04) が古く、サポートも終了しているためこれを機に OS をアップデートした。

Kubuntu はデスクトップ環境として非常に気に入っていたのだが、 2026 年 4 月に次期 LTS のリリースを控えているタイミングで敢えて 25.10 を導入するのも何だかモヤモヤするものがある。 KDE 環境が好きなのと、OS のアップデートサイクルに対する心理的負担を軽減したかったので、結果として今回は OpenSUSE Leap をインストールすることにした。

パッケージマネージャーが apt から zypper へ変更された点を除けば、主な開発ツールは mise を経由して管理しているため、ディストリビューションの違いによる開発体験への影響はほぼなかった。

またそれに合わせてノート PC (Windows 11) の WSL2 環境も OpenSUSE Tumbleweed に変更した。これは全く必要のない変更だったが、デスクトップ PC と OS を揃えておくことで片方で得た知見がもう片方で活きるのでは？という期待を込めての変更である。 WSL2 上での開発は主に VSCode のリモート接続や Docker コンテナのホストとしてしか利用していないため、以前使っていた Ubuntu から別のディストリビューションに変更したところで開発スタイルには特に影響しなかった。

AI エージェントを活用した開発スタイルの模索

AI エージェントの活用といっても様々なアプローチが存在するため、いくつかのツールとモデルの組み合わせを検証した。選定したのは月額 1000 円程度で利用できるツールとモデルである。

プラットフォーム: Antigravity, VSCode + Continue, Aider, Cursor
ミドルウェア: Ollama
学習モデル: Qwen2.5-Coder, Gemma 3, APN1-NovaPro, Gemini 3 Pro

各組み合わせを試した結果、Antigravity + Gemini の構成が最も安定したパフォーマンスを発揮した。 VSCode + Continue や Aider もそこまで悪い開発体験ではなかったが、同一の試行錯誤を繰り返すことが何度もありトークン消費の観点であまり好感が持てなかった。 Cursor は評判が良いので、きっとデフォルト設定で使用する分には開発しやすいのかもしれない。だが、今回試したようにカスタムモデルの利用を前提にすると設定に手間取る印象を受けたので、あまり詳細に検証していない。

そういえば最近話題の Claude Code や Gemini CLI といった CLI ベースのエージェントツールは、興味はあるものの検証出来ていない。特に複数エージェントを協調させる開発手法は試してみたいが、トークン消費が青天井なのでは？という懸念から実際に触れていない。だがこれらの CLI ツールは開発以外にも使える他、エディタを選ばないという利点があるため近いうちに検証したい。

正直これまで開発するためのツールにあまり課金をしてこなかったので、トークンの入出力で月に何千円も払うという感覚に馴染めていない。だが仮に AI エージェントツールに毎月 5 万円払うことになっても、それによって自分のアウトプットが増えて結果として単価が上がるのであればペイ出来る金額だとも思う。

これまでであれば自分の時間を勉強に充てていることがエンジニアとしての自分の席を確保するためのチケットだったのが、これからはそれ以上に AI ツールに惜しまず課金をしていることが席を確保するためのチケットになるのかもしれないと思うと少し複雑な心境だ。

エージェントへの作業依頼は 001.order.md のような要件定義ファイルを作成し、このファイルを通じて実装を依頼するスタイルである。この方法は数年前に流行った所謂プロンプトエンジニアリングに近いのではないかと考えているが、実装前に綿密な要件定義や設計を言語化する必要があるため機能開発に対する自分自身の理解度を上げる効果もあり、私自身には非常にマッチしていると感じているし、実務を前提とした場合も良いアプローチなのではないかと思う。

この方法で開発を進めるのであれば開発速度の上昇というメリットは享受しつつ、なぜこのような実装になったのか？等、後からコードを振り返る際に当時の実装意図が揮発してしまうというデメリットも軽減できるのではないかと思う。少なくとも「AI が出力して、動くから良いかと思った」というような状況は避けられるはずだ。

一方で、昨今流行りの MCP や Skills を活用する開発スタイルにまでは至らなかった。今回は連携したい外部ツールはなかったので MCP は無理に使用するつもりはなかったが、 Skills は最近の話題でもあるし触ってみても良かったかもしれない。ただ Antigravity にはまだ機能が搭載されていないようだったので試すなら Gemini CLI を試すときに一緒に試すのが良さそうだ。

2026年1月後半: TypeScript の再学習とバックエンド構成の検証

TypeScript アプリケーション開発

ToDo管理アプリの実装を通じてキャッチアップを行った。これまでの業務でも TypeScript に触れる機会はあったが、既存コードの改修が主であり 0 -> 1 のプロジェクトのセットアップやアーキテクチャ設計は経験がなかったので良い機会となった。

技術スタックは以下

バックエンド: TypeScript, Express, Prisma
フロントエンド: TypeScript, React, MUI, Vite

少し実装が大きくなってもやっていけるくらいの分割（ハンドラとサービスの分割くらい）を意識しつつ基本機能を実装した。 API の初期実装を手動で行い肌感をつかんだ後、残りの実装は AI エージェントに委譲するようにしてみた。

所感

tsconfig: tsconfig.json の設定が難しく感じた。特に target や module などの設定項目は、内容次第で実装する際の記法に影響が出るため、ある程度以上の知見が無いと適切な設定が難しいのではないかと思う。
pnpm: 以前から利用していた npm / yarn と比較して動作が高速であり、依存関係の管理もクリーンで開発体験が良かった。
Prisma: データベース駆動での開発ではなく、スキーマ定義（.prisma）から型安全なクライアントモデルを自動生成するアプローチは宣言的でとても好ましいと感じた。

2026年2月前半: Go 言語の習得

Go の基礎学習と Web アプリケーション実装

TypeScript のキャッチアップと同様に、ToDo管理アプリの実装を通して Go 言語の学習を行った。 A Tour of Go で基本的なシンタックスを学習した後、具体的なアプリケーションの構築に着手した。 Go の「例外処理は基本的に error を戻り値として扱う」というシンプルかつ明示的な設計思想が非常に好印象であった。

技術スタックは以下の通り。

バックエンド: Go, Echo, Ent, Google Wire
フロントエンド: TypeScript, Next.js, Tailwind CSS

所感

A Tour of Go では Goroutine や Channel を使った並行処理を学ぶことができたが、実際のアプリケーションでどのように活用すれば良いのかイメージが湧かなかった。
- そもそも Echo を使ったサーバーサイド開発においてこの手の並行処理を書く機会は多いものだろうか？まったく書かないとは言わないが (これまで自分が経験した Python のサーバーサイド実装でも並行処理を書く機会はあったので) 、正直少ないのではないかという印象を持った。 Web 以外の用途で Go を使う際は有用そうに思うが、 Web でやる場合は Queue をアーキテクチャに組み込んで非同期かつ並列で処理してしまうことが多いんじゃないだろうか。
Ent: Prisma と同様の「スキーマ定義からのコード生成」アプローチを採用しておりこちらも明示的でわかりやすかった。
- スキーマ定義からモデルをコード生成するのが昨今の ORM のトレンドなんだろうか？
Google Wire: 依存性の注入 (DI) をコードジェネレーションによって解決する仕組みが面白く、明示的で分かりやすいのも好印象。
context.Context: コンテキストの取り回しは便利だが、設計を誤ると何でもかんでも context に詰め込むような実装につながりかねないため、適切な設計パターンを学ぶ必要がありそう。
Next.js & Tailwind CSS: Next.js のファイルシステムベースのルーティングは、React Router のような宣言的なルーティングと比較すると暗黙的な要素が多いため好みが分かれるかもと思った。Tailwind CSS は MUI などのコンポーネント指向ライブラリと比較すると記述量が増えるが、デザインの自由度やカスタマイズ性は高いのでデザイナーさんのセンスを最重視するプロダクトでは良い選択肢となりそう。