5
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

2025年末、さぁ完璧を目指さずに生成AIと付き合おうか

Last updated at Posted at 2025-12-04

前置き

本記事は、生成 AI プロダクト開発の話ではなく、日々の業務で生産性や効率をどう上げているか という視点に絞っています。
以下に私の業務概要を書いたので、その前提を踏まえて読んでいただけると嬉しいです。

※ そもそも生産性とは何か?本当に上がっているのか?という疑問はあります…。

私の業務

  • UI デザインの理解やコードとの橋渡し

  • フロントエンドエンジニアリング領域内の UI 寄り領域の業務(マークアップやアクセシビリティ対応など)が多い

    • IoT や BtoB などの Web アプリのガッツリ開発に携わることは少なめ(UI 調整で関わる場合はある)

生成 AI モデル

主要モデル

Claude

Anthropic の提供モデル。

個人的な感覚

  • 作業の自立性が高く、複雑なタスクも進める力が強い
  • 日本語の文章の質が高いという点で、日本語の理解力や生成力が高い
  • 他のモデルと比べて、トークンあたりのコストが高い
  • UI デザイン力が他モデルより相対的に高い印象
  • 4.5 Opus しか勝たん

最近のモデル

  • Claude 4.5 Sonnet
  • Claude 4.5 Haiku
  • Claude 4.5 Opus
GPT

OpenAI の提供モデル。

個人的な感覚

  • プロンプトへの感度が高い
  • 0 → 1 よりも 1 → 10 のような改善タスクに強い
  • UI デザインは、Claude より弱い印象
  • 日本語の指示に対する理解力は高いが、日本語文章の生成は Claude ほどではない印象
  • 他のモデルと比べて、トークンあたりのコストが安い
  • 複雑なロジックの実装や修正は、Claude や Gemini よりも Codex を使うことが多い

最近のモデル

  • GPT-5.1
  • GPT-5.1 Codex
  • GPT-5.1 Codex Max
Gemini

Google の提供モデル。

個人的な感覚

  • リリース当時は、他モデルと比べて全体的にパフォーマンスが優れていた印象。現状は他モデルのアップデートにより相対的に見劣りする部分もある

  • 検索力が高い

  • UI 生成力は Claude より弱い印象。ただし、Nano Banana のような画像特化モデルもあるため、今後の発展に期待

  • Gemini 3.0 に期待

    • などと言っていたら出ました。Antigravity も含め「やっぱり Google さん強いな〜」とは思いつつ、個人的には Opus 4.5 派です。ごめんなさい。

最近のモデル

  • Gemini 3.0 Pro
その他
  • Grok

  • Llama

  • OSS(AI の研究者の方々などに喜ばれているらしい。個人開発者も使いやすい)

    • GPT
    • Llama
    • DeepSeek

Gemini もそうですが、各社 LLM モデルにはそれぞれ「思考の癖」があるように感じます。すべてを自分で試せているわけではないものの、X を眺めているとなんとなく傾向は見えてきます。

例えば、Claude はフロントエンド領域のコーディングや日本語の長文ドキュメント作成において第一選択肢になっているように感じます。GPT は、Claude よりももう少しロジカルな関数を書かせたり、調査をさせたりするときに使われがちです。Gemini は直近のアップデートでフロントエンド領域が強くなったので、Claude と同じような用途で使われつつ、母体である Google の検索力を生かした調査役としても期待されている印象です。Grok はリアルタイム性と、レスポンスの速さ・安さが魅力とされているように思います。

こうした違いはいわゆる「モデルの特性」と呼ばれるものかなと思います。バージョンアップによって見え方が変わったり、弱点が解消されたりはありますが、根っこの特性はある程度残っている印象です。

もちろん、Claude がフロントエンド領域に強いからといって、フロントエンド全般で常に他モデルより優れているわけではありません。タスクの内容によっては GPT の方が適していることもあり、その間には結構グラデーションがあると感じます。

ここまで主観でだべってきましたが、「じゃあベンチマークってどうなの?」という話もあると思います。私自身ものすごく調査しているわけではないので推測も含みますが、ベンチマークの値は、特定のテストセットに対するスコアです。当然、そのテストの内容によって、どのモデルがどんな数値を出すかは変わります。

そのため、「ベンチマークで ○○ モデルが一番だから最強!」と思っていても、実際に自分のタスクで使うと「え?あんまり凄さを感じないけど…」ということはよく起こります。

また、このベンチマーク算出のためのテスト自体も、AI が学習してしまう(テスト慣れしてしまう)と言われています。そこで、より新しく、まだ AI が慣れていないテストセットを作る、といった試行錯誤も続いているようです。

別件ですが、モデルに関しては Cursor や Windsurf といった、後述する AI IDE 提供企業も独自モデルを搭載し始めています。結局モデル性能は重要ですし、大手の API コストもバカにならないよな〜と感じています。


生成 AI エージェント

CLI(コマンドを駆使し、チャット形式で作業する)

  • Claude Code CLI
  • Codex CLI
  • Gemini CLI
  • GitHub Copilot CLI
  • Cursor CLI

個人的には、CLI 型のエージェントが一番使いやすいと感じています。UI の変更についていかなくていいので。
また、bash や zsh などのシェルや、GitHub の gh コマンドなど、コマンド同士の連携がしやすいのも良い点です。

一時期は Claude Code よりも Codex の勢いが強かったですが、最近はまた Claude Code に戻っている方が多い印象です。
最終的には、カスタムコマンド機能・サブエージェント機能・スキルズ機能といった機能面の充実度や、世間の MCP サーバーサポート率の高さから、Claude Code CLI が強いと感じています。

GUI(コードエディタなど)

  • GitHub Copilot(VSCode)
  • Cursor
  • Windsurf

元々 VSCode を使っている人には、GitHub Copilot が一番馴染みやすい印象です。
AI 機能重視で情報を追ってきている人は、Cursor や Windsurf を使っているケースが多いように見えます。

直近だと Cursor の機能アップデートがすごく、話題になることが多いです。また、Cursor は Composer、Windsurf は SWE-1.5 などの独自新モデルを導入していて、こちらも盛り上がっている印象です。

そういえば、最近 Google から Antigravity も出ましたね。
Gemini 3.0 Pro との組み合わせが良い、と発信している方をよく見かけます。

自分は正直ついていけていないのと、Gemini 3.0 をまだそこまで良いと感じられていないので、今は足踏み中です(Nano Banana Pro は一線を超えた感じがして、かなりすごいなとは思っています)。


他の AI ツール

  • Figma Make
  • v0

2023〜2024 年頃は、他にも盛り上がっているものがいくつもありましたが、最近は少し落ち着いてきた印象があります(単に自分が追えていないだけかもしれません)。

その理由としては、例えば次のような点があるのかなと感じています。

  • ツールの特性上、既存プロダクトやサイトに導入しづらい
  • 導入したとしても、理想通りのものを作成するまでに時間がかかりすぎる
  • Codex や Claude Code、Cursor の汎用性や生成能力が高すぎて、相対的に見劣りしてしまう

結果として、Figma との連携が強力すぎる Figma Make や、Git 連携が強く Vercel + Next.js との相性が良い v0 あたりが、今もなお使われている印象です。

2025 年現在は、CLI や GUI のコーディングエージェントツールが強く、v0 のような GUI 上だけでぽちぽち触るツールの盛り上がりは、一段落しているように見えます。とはいえ、LLM モデルの進化が進んで、開発者がコードを直接編集しなくてもモノになる世界線が来れば、再び盛り上がる可能性は十分あると思います。
また、他のツールとの連携がよりスムーズになる方向でも、同じように再注目されるかもしれません。

プロトタイピングツールという文脈で見ると、そもそも「生成 AI × デザイン」は、「生成 AI × コード」に比べると相性がそこまで良くない気もしています。デザインはコードに比べてロジカル要素が少なく、生成 AI が得意とするパターン認識やルールベースの処理が効きにくいからです。

もちろん、デザインの中にもグラデーションがあります。Web アプリやネイティブアプリあたりの UI デザインは比較的ロジカル要素が多いので、アーティスティックな LP や Web サイトなどに比べると、生成 AI との相性は良いと思います。

ここら辺の話も、数年後にはだいぶ解決されている可能性はあります。

個人的な願望としては、Figma Make の生成機能(Figma デザインデータ変換も含む)がさらに進化し、機能拡張(SEO 周りや Git 操作の自由度向上など)も進んでくれると、飛び跳ねて喜びます(すでに短期スパンで色々来てはいますが)。


周辺情報

  • プロンプト
  • コンテキスト
  • MCP

プロンプトは、ここ数年生成 AI を使用する上で、最も重要な要素の一つと言われてきました。「プロンプトエンジニアリング」という概念が生まれるほどです。ただ、最近の LLM モデルはかなり賢くなっていて、昔ほど気を張ってプロンプトを書かなくても、それなりに良い出力が返ってくるようになってきました。

とはいえ、依然としてプロンプトの質が生成内容に与える影響は大きいです。モデルによってプロンプトへの感度も異なるので、使うモデルに合わせたプロンプト設計は、今後もしばらく重要だと思います。

コンテキストに関しては、おそらく LLM モデルが進化してもしばらくは「最重要項目」の一つであり続けるはずです。その都度のプロンプトや、参照させるドキュメントなどを開発者自身が把握し、生成 AI に適切に渡す必要があります。コンテキスト 0 よりは多い方が良いですが、多すぎると処理が重くなったり、出力がブレたりします。「何をどこまで渡すか」という意味で、コンテキストの質もかなり重要です。

MCP に関しても、生成 AI 周りではデファクトスタンダードになりつつあるように感じます。MCP という概念は、前述のコンテキストに深く関係していて、主にコンテキストをリッチにし、生成 AI の性能を最大限に引き出すための仕組みとして重要です。

大きく分けると MCP クライアント・MCP サーバーの 2 軸があり、サーバー側の設計まで触ってみると、全体像の理解が一気に深まるのでおすすめです。

▶︎ MCPをデファクトスタンダートとかいっていましたが、一概にそうは言えなさそうです。ツールをしっかり使ってくれない・コンテキストを圧迫しすぎるなどの短所があり、加えてMCPを使わずともClaude CodeならSkillsやアブエージェントを駆使したり、Pythonのスクリプトで実現した方が、よりシンプルでブラックボックス化しないという意見もあるようですね。いやまぁそりゃごもっとも。


生成 AI を交えた開発

  • デザインシステム
  • レビュー
  • テスト
  • 要件定義(仕様)
  • ドメイン知識
  • CI/CD

現状は、生成 AI にハンドルは持たせつつも、人間が最終的な品質管理を行う形が主流かと思います(すなわち、人間が補助している状況)。

ただし、徐々に生成 AI の性能は上がってきており、将来的には人間の関与度合いが減っていく可能性もあります。そのときに備えて、「生成 AI に仕事をさせやすい」ように、開発体制やワークフローを見直しておくことが重要だと感じています。

このあたりを整えておけば、仮に AI があまり仕事をしてくれなくても、人間にとって効率的な開発体制になるので、生成 AI を使わない場合でもメリットがあります。

(開発フローのどこに生成 AI が入りやすいかを図にするとこんな感じです)

ちなみに、最近自分が特に興味関心を持っていて、個人的に力を入れているのは、レビュー・デザインシステム・テスト・リンター・フォーマッターの領域です。まだまだ試行錯誤が続いています。

テストに関しては、活用はできますが、自分自身でもエッジケース網羅したテストが書けたりした方が、当たり前ですが良いですよね。


今後の動きの予測

  • AI の使い方、今のままでいいの?

    • 生成 AI ツールの進化に伴い、今後は 1 to 1 のやり取りだけでなく、「ワークフロー化」していく動きが強くなると思います。
    • 単なる効率化ツールとして使うだけでなく、生成 AI やそれを組み込んだ何かを開発する方向性も、さらに加速していきそうです。
  • 生成 AI とのやりとりは、Chat UI だけでいいの?

    • 開発者はチャット UI でも難なく作業できますが、一般ユーザーが AI エージェントを使う場合、本当にチャット型 UI が最適なのかはまだ議論の余地があると思います。音声 UI や VR 方面も今後強化されていくはずです。
  • UI の需要・Web サイトは必要?

    • 一時期、SNS 上でも盛り上がっていたテーマで、議論になっていました。
    • 海外の大手企業の CEO(HubSpot や Cloudflare など)が、Web サイトの閲覧数低下に言及しているのも見かけます。
    • 一定の需要はもちろん残ると思いますが、AI フレンドリーで、AI 検索から情報を拾ってもらいやすいサイトや、AI に MCP として接続できるサイト・サービス以外は、基本的に閲覧数が下がっていく。その結果、AI フレンドリーなものとそうでないものの差が大きくなっていきそうです。
    • また別の問題かもしれませんが、AI 検索による大量クロールで Web 上の公開サイトに負荷がかかっている、という話も耳にします。ここも今後何らかの対策が進んでいくのか、個人的に気になっています。

まとめ

色々書き殴ってきましたが、お忙しい中ここまで読んでいただきありがとうございます。
正直、特別ユニークな知見を書いているわけではないかもしれませんが、どこかで皆さんの AI 事情も教えていただけると嬉しいです。

P.S.
自分ではここ数年、AI をできる限り色々試してきてはいるものの、「終わり」や「絶対解」はないなと思っています。

楽しめている自分もいますが、最新情報のサーフィンに時間を溶かしてしまい、「もっと先にキャッチアップすべきもの」や「基礎学習」を疎かにしないようにしないとな、とも感じています。

まあ、こうした努力も徐々に「なくても仕事できる」世界になっていくのかもしれませんが、少なくとも 2025 年 12 月の段階だと、以下を高速かつ精度高く繰り返せる必要があるのかなと思います。ミドル〜シニア以上の方だと、すでに知見の貯金がある分、キャッチアップの量はジュニアより少なくて良いのかもしれません。

  • 生成 AI を最低限使えるように慣れておく

  • 生成 AI を使って、壁打ち的に最速キャッチアップを行う

    • そのままだと知識が虫歯になるので、名著や公式ドキュメント、OSS なども読み、体系的に身につける
  • アプリやブログなど、何かしらの形でアウトプットする

生成 AI に限らずだと思いますが、理解の深さには以下のようなグラデーションがある気がしています。それぞれの層で、見えている世界や意見の解像度がだいぶ違うな、と。

  • 聞いたことない
  • 聞いたことはある
  • 理解している
  • 使ったことある
  • 使い込んでいる・使いこなしている
  • 自分で作っている

解像度を上げたい場合は、やはり最低限「実際に使ったことがある」〜「ある程度使い込んでいる」くらいまではいく必要があるのかもしれません。

ただ、完璧を求めすぎるとどこかで壊れてしまう気もしています。少なくとも自分はそこまでストイックには持たないと思うので、自分のペースで、自分が興味を持てる領域を中心に深掘りしていくのが得策かな、と今は思っています。

参考資料

5
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?