はじめに
2025年ももう年の瀬なので、今年のまとめと外せない生成AIについて雑感を残しておきたいと思います。
← と思っていたら、投稿が年越しちゃいました(笑)
(完全手動記事です)
AIコーディング
個人的なAIコーディングの走りでは、
2023年のGithub CopilotやAWS re:Invent 2023のCodeCatalystとAmazon Qを組み合わせたチケット開発だったと記憶しています。
(会社ブログに当時の設定方法をまとめていました)
https://www.beex-inc.com/blog/aws-codecatalyst_and_q
また、衝撃を受けたのは昨年末に発表されたDevinでした。
(個人ログさかのぼってもちゃんと紹介記事出てきました。当時は高くて手が出せず。。。)
https://publickey1.jp/blog/24/aidevin500.html
その後は、recline、Roo Code(旧Roo-Cline)、OpenHands、Cursor、Gooseなどいろいろ経由した挙句、
VSCode + Claude Code、Codexに落ち着いています。
様々なプランも契約していました。
- Cursorの年間契約(少し判断早まりすぎた感はありましたが)
- ClaudeやGPTの月額高級プラン($200くらい)
- 生成AIに関わるメンバーシップなど
ただ、各種クラウドプロバイダ連携(AWS、Azure、Google Cloud)も時間がたつにつれ整備されてきたため、今ではCluade $20とGPT $20の軽量プランだけになりました。
もちろん、代わりにクラウドプロバイダの課金額はうなぎのぼりです。
とある月ではAWSのBedrock課金額のみで$1000超えるくらいにはClaude Codeでぶん回しておりました。
(弊社、本当にありがとうございます)
業務適用
AIエージェントによる作業効果はどうだったのかというと、(個人的には)抜群に効率が良くなったという印象です。
今年の前半では、仕様書、テスト観点を手動作成した後のコード実装とIaC設計、実装(AWS Cloudformation)をコーディングエージェントを使ってどう実装するかに苦心していました。
特にIaCコードであるCloudformationの実装については要件も明確化しやすく、書き方も比較的複雑でないため、設計、実装ともに有効であることに手応えを掴んでいました。
対して、アプリコードについては、過去のコンテキストの考慮や設計書上の表記次第で実装が不安定になりやすく、人の手が入る必要がまだまだ多かった印象です。
後半に入ってからはAmazon Bedrockへコーディングエージェントが対応したり、Claudeの月額高級プランを契約したりしたため、
前半より広範なタスクに利用し、初見の技術調査やデモアプリ作成、ライブラリバージョンアップ、ハンズオン作成など、ほぼ全ての業務でコーディングエージェントを利用しないものはないと言えるくらい利用していました。
そうした中で、コーディングエージェントのセンターピンは以下の言葉に集約されると思います。
「魔法はイメージの世界だ。イメージできないものは魔法では実現できない」リヒター（『葬送のフリーレン』より）
AIを使って何がしたいか、
何をどうやって作るのか、
アプリケーションアーキテクチャ、インフラアーキテクチャは何を採用するのか、
どのプログラミング言語、ライブラリを使って作るのか。
自分のイメージしたものをプロンプトに言語化し、それを実現させることがAI活用の本質だと最近、感じています。
精神的な変化
コーディングエージェントを多く使ってきた中で、昨年までと精神的な変化もいくつか感じています。
アイデアを形にしやすくなった
こうした技術検証をしよう、検証した結果を文字に起こそうというアイデア自体は業務内外であると思います。
そのため、アイデアをAIに伝え、検証してもらい、その結果を文字に残すということがとても気楽にできるようになりました。
(元々、技術検証は多くしていますが、ドキュメントにまとめるのが面倒で、お客さんに出したもの以外で残っているものはあまりありませんでした)
自分の能力が拡張した感覚
いわゆるSI的な業務に携わっている中で、従来は自分の時間をどう使ってバリューを出すか、その中で技術的に楽しいことをどう含めるかという観点で仕事をしていました。
ただ、コーディングエージェントを使っていく中で、自分のできる限界値が「自分の時間で出せるバリュー」とイコールだったのが、「自分の時間 + AIエージェントを使って出せるバリュー」に変わってきたと思います。
(割り当てが1人月超えてもAI含めたら対応できるという感覚)
これはコーディングエージェントを使い続ける中で、
ここまでならコーディングエージェントに依頼ができて、これくらいの品質まで生成できる、自分がどれくらい稼働すればアウトプットまで持っていける
という感覚値が育ってきたからではないかと思います。
自動化できないプラットフォームへの忌避感の強化
上記の自分の能力値をAIを使って拡張できている感覚がある上で、対照的に、APIやMCPを使えない社内システムやPPT、Excelといった無駄に時間を取られる業務に忌避感がより強くなりました。
新規提案などの価値のあるPPT作成などは苦にならないのですが、
単純な日々のワークフローで使われているシステムでの作業や数ヶ月に1回、日付だけを書き換えるようなPPTなど思考が不要で作業と化しているワークをAIで自動化したいと思います。
ただ、プラットフォーム制約でしにくいという部分にすごくストレスを感じるようになったと思います。
人よりAI
比較的、1人もしくは少人数でお客さんと相対するプロジェクトが多く、そういった中でAI活用をする余地が大きかったです。
ただ、コーディングエージェントをある程度上手く使う技術が向上した代償に、人に何を任せるべきかが難しくなったと感じています。
もちろん、特定の技術領域が得意などのシニアエンジニアには任せてしまえますが、そうでない場合、実装速度やレビュー負荷、コミュニケーションコストを踏まえると、
明確な育成であると調整されていなければコーディングエージェントの代わりで人に任せることを選択しにくいと思います。
2026年の個人的方策
技術の幅を広げる
センターピンから逆算するとイメージの幅を広げることがAI活用の基盤であり、それは技術の幅を広げることが対応すると思います。
そのため、データ分析基盤、マルチクラウド、MLOps、プラットフォームエンジニアリングなど今の自分の技術スタックに+αをするための学習や経験を積むことが必要だと考えます。
AIトレンドの追従
上記の幅の中にAIはもちろん含まれるため、業界Topを走らずとも追従し、活用し続けることは必要だと考えます。
アーキテクトとしての振る舞い
広げた幅を活かすような新しいことをするためには課題の近くにいる必要があります。
そのため、「課題を解決するために何を作るか」を考えるアーキテクト的ポジショニングをとりつつ、
得た知見とAIを組み合わせてHowを高速実装することを目指します。