生成AIツール大全 @ 2025

生成AIツール大全  モデル・ツール・ユースケースを一気に整理

仕事: 自動運転系のソフトウェア開発、副業ではWeb開発(フロント: TypeScript, React、バックエンド: Python, NodeJS, Go、インフラ: Terraform,
aws cdk) 本業、副業ともにLLMを使った開発を行っています。大学の研究: GCNを用いた医療用アトラスの構築趣味: バスケットボール、野球観戦(阪神🐅)、ゴルフ⛳ 名前 : 梅原隆一

生成AI使えてますか...？ • とにかく数が多すぎる... • 毎週のように次々と新しいツールやモデルが登場 • 正直仕事で使えてない... 出典: 一般社団法人NoCoders Japan協会
  キャッチアップが  大変すぎる... 

本日の目標 • 生成AIツールの全体像が整理できている • よくある開発への具体的な活用方法がわかる • 「とりあえず使ってみる」から一歩進んだ、戦略的な生成AI 活用の入り口に立てている開発者視点での 

アジェンダ 1. 生成AIを取り巻くエコシステム全体像 2. IDE・開発支援ツールの紹介と比較 3. エージェント系ツールの進化 4. よくあるユースケースとおすすめツール 5.
自分なりの選び方・使い分けの観点と導入Tips

プロバイダー  開発者視点でのLLMの枠組み  エージェント  MCPサーバー  Base Model 

LLMとは  • Large Language Model (大規模言語モデル)  ◦ 大量のテキストデータを学習し、人間の言葉を理解し、生成する能力を持つ   •
最近では以下の技術も  ◦ マルチモーダル  ▪ 自然言語だけではなく、画像、音声、動画も入(出)力できる   ◦ Reasoning  ▪ 単なる応答だけではなく、人間の思考を模擬。AIの思考過程も出力できる   ◦ Mixture of Expert  ▪ 三人よれば文殊の知恵   ▪ 異なる特徴を持つモデル(エキスパート)の集合体   ▪ タスク(入力)に応じてどのエキスパートをどれぐらい重みづけるか決定  

ざっくりLLMの歴史  • RNN, LSTM時代(2010年代以前)  ◦ 入力と1つ(以上)前の出力を使って次を出力   ◦ 学習速度に難あり、コンテキストも狭い  
• Attention, Transformerの登場(2017)  ◦ 文章をまとまった単位で一括で処理可能に   ◦ 学習速度の向上、コンテキストが広く   • GPTの登場  ◦ Generative Pre-trained Transformer(2018)   ◦ GPT-3.5 (2022)  ◦ パラメーター数の急増   input  output  Model 

おすすめBaseModel Claude Sonnet 4  • オーソドックスで優秀  • 文脈を理解してくれて雑な指示でも使いやすい。  •
イチオシ  • (高性能すぎて不要なメソッドを生やしがち)  • Claude Opus 4を使いたいが高コスト  Gemini 2.5 Pro  • コンテキストが長くても理解してくれて優秀。  • 設計も実装もバランスが良い。(気がする)  OpenAI GPT-4o  • ClaudeやGeminiと比較するとコーディングは苦手な印象  • 設計に関しては、結構使える  • Grok4も試してみたがあまりエンジニアリング向け   では無さそう  • 上記は基本的にClosedだが公開されたOpenWeightも   ◦ Kimi-K2  ◦ Qwen3-Coder 

Bench Mark • LLMの性能を評価するための「テスト」  ◦ 色々なタイプの性能を評価するためのベンチマークが存在    • LLMの特性を理解するためには  代表的なベンチマークの種類と 
特性をざっくりと把握する必要  がある。 

代表的なベンチマーク • MMLU(2021)  ◦ 歴史、数学、法律、CSといった問題を選択形式で出題  ◦ 最近のAIだとほとんど80%以上の正答率をマーク。  • SWE-Bench(2024)  ◦
GithubのissueからLLMにPRを作らせてUnitTestがPassするかを検証  ◦ Claude Sonnet 4がやはり強い。大体60%を解く  • HLE(2025)  ◦ Humanity’s Last Exam  (人類最後の試験)  ◦ 博士号以上の難易度の問題が並ぶ 

余談: HLEのサンプル • プローブ極限におけるD3/D7配置に基づくボトムアップ・ホログラフィックモデルの文脈において、バルク背景を5次元のアインシュタイン・ガウス・ボンネ計量とし、フレーバーセクターがゲージ場とスカラー場から構成されているとします。ガウス・ボンネ結合定数が0.1の場合、スカラー場に双対な演算子の凝縮に対する臨界化学ポテンシャルの値は何ですか？ 

余談: HLEのサンプル • プローブ極限におけるD3/D7配置に基づくボトムアップ・ホログラフィックモデルの文脈において、バルク背景を5次元のアインシュタイン・ガウス・ボンネ計量とし、フレーバーセクターがゲージ場とスカラー場から構成されているとします。ガウス・ボンネ結合定数が0.1の場合、スカラー場に双対な演算子の凝縮に対する臨界化学ポテンシャルの値は何ですか？  答え: 2.2 

クラウドベンダー系  • AWS Bedrock  • GCP Vertex AI Cloud 
• Azure OpenAI Service  その他  • OpenRouter  • Groq  • 自社モデル  ◦ ChatGPT  ◦ Grok  ローカル  • LM Studio  • Anything LLM  モデルプロバイダ 

とりあえず試すならOpenRouter  • 従量課金制のモデルプロバイダ。いろんなモデルを少額で試せる。  ◦ Grok4を使うには公式だと月額30ドル必要...  • APIキーも発行できるのでエージェントとしての使用も可能  ◦ APIキーごとに残高を設定できるので使いすぎない。 

OpenRouterでGrok4使ってみた  • 多様なソースをみながら方針を決めてくれる。  • 技術的な部分の知見は弱そう。  • エンジニアというより
ITコンサルと話している感じ 

VSCode • 王道 • copilotによる自動補完とエージェント機能が使える • 使えるモデルが
少ない印象 Cursor • 自動補完やエージェントなどが標準装備 • UIやショートカットが VSCodeから結構改変されていて好き嫌いが分かれそう IDEとLLM Kiro • VSCodeにかなり近いUI • Spec Driven Development • まだリリースはされていないが期待値は一番かも

Kiro • Kiroの特徴  ◦ 基本機能  ▪ MCP, Agent, 自動補完, rulesファイル(steering) 
◦ Spec Driven Development  ▪ 仕様書を書いてそれに沿うソフトウェアを作成  ▪ LLM開発のベストプラクティスをUXに落とし込んだ開発体験  ◦ Hooks  ▪ 自然言語で特定の操作の後に自動で走らせる処理を記述できる  • linterなども使える  ◦ 使いやすいUX, UI  ▪ VSCodeのUIのいいところ + Kiro独自のUI  ▪ Claude Codeのような設定を自然言語+わかりやすいUIで表現 

なぜSDDなのか • 仕様→設計→実装→テストの順で修正コストが高くなる。  （NARAコンサルティング奈良隆正さんのソフトウェア品質保証の方法論、技法、その変遷～先達の知恵に学ぶ～P31より引用）   • LLMによって負債の増殖する  スピードも増えた  ◦ AIのコードのレビューも大変 
◦ LLMのトークン数も増える  (つまりコストが増える)    • 仕様の段階でLLMと認識を合わせることで結果的に実装が速くなる！ 

Spec Driven Development(SDD) • 3種類のドキュメント  ◦ requirements.md  ▪ 要求仕様をEARS形式でかく(WHEN ~~
THEN SYSTEM …)  ◦ design.md  ▪ ワークフローやアーキテクチャ図からテストに用いるライブラリまでプロジェクト全体の技術的な設計が書かれる  ◦ tasks.md  ▪ 実際に作業するタスクリスト  • 人は数行のプロンプトを伝えるだけでLLMがこれらを書いてくれる。  ◦ チェックするだけで良いのですごく楽ちん 

Kiroを使ってみた • 今回作ったアプリ  a. AIのPRレビューと実装のサイクルを自動化するアプリ  • 流れ  a. KiroでPRを作る  b.
gemini code assistが自動でPRをレビューしてくれる  c. →PRにコメントをついたことを確認してKiroのエージェントにコメントついたから直してとお願い  d. b,cのループ(一定回数)  e. 手動でマージ 

requirements.md

design.md

tasks.md ちょっと粒度は大きいが小分けにしながらタスクを進められる。 

使いやすいUI/UX VSCodeと同じ  サイドバーUI  仕様書やHooks,  Streering,MCPにすぐアクセスできる 

イマイチな点 • どのタスクから進めればいいかわからない  ◦ ユースケースなどの高レイヤーから実装  ▪ ちゃんと動くんだろうかという不安を持ちながらレビュー  ◦ repositoryなどの低レイヤーから実装  ▪
不要なメソッドを生やしがち。レビュー負荷の増大やtokenのコストが非線形に増える  • タスク1つ1つの粒度が大きい。  ◦ PRが大きくなりがちでレビューするのが大変。  • まだまだ細かいバグが多い。  • (KiroというかLLM全体の問題)  ◦ エラーハンドリングが雑すぎる  ◦ 型ヒントが雑すぎる。  ◦ Steeringで一定の改善はできる。 

CI / CD PR Agent • OSS • PRのtitle, description
の自動記載 • PRの自動レビュー&自動修正 gemini code assist • 無料で使えて、レビューの精度も良い。 • ちゃんとREADME.mdなどを読んでレビューしてくれる。 • 日本語対応が弱いのがネック。(日本語指定してもたまに英語で返ってくる)

エージェント型 devin  IDE搭載Agent  • Github Copilot(VScode)  • Cursor, Windsurf  •
Kiro  • 大体どれも似たり寄ったりの機能   • 完全自律型  エージェント  • 本当に人みたいに働く  • slackやgithubの連携など本当に人みたい。  • (初期)コストが高い  (最近500ドル → 20ドルに下がった)   • OSS版としてOpenHandsがある  ClineやClaudeCodeなどの単体?のAgentも存在。   IDE搭載Agentよりも体感として2,3倍速い印象。   従量課金を許容できるならアリかも。  

devin使ってみた  • 完全自律型なのでタスクを任せっきりにできるのが⭕  ◦ 作業完了したらビープ音鳴らしてくれたり通知くれたりするのが良い。   • 出てくるコードの質も⭕   ◦
(claude sonnet 4とかよりも自然な感じ)   • コンテキストが途切れない⭕  ◦ 途中で指摘をすると、その指摘内容が次回以降のタスクに自動で引き継がれる   • Devin Wikiが便利⭕  ◦ Wikiには内容だけではなく、根拠となるソースも書かれる。   • (くそ)高けぇ❌  ◦ そもそも1タスクにかかる時間が長いので必然とコストも高め。   ◦ 丁寧にコンテキストを読んでくれてる感じ。   ◦ 使ってなくても自動スリープするまで課金されちゃう   ◦ 小規模コードベース x kiroによるドキュメントでも10分ぐらい使って15＄   (cline x claude opusとかに比べると安いが)  

MCP  • Model Context Protocol  • LLMモデルと外部リソースの間で通信する仕組み  ◦ AIモデルのための仮想的なUSBとも言われる  
• LLMモデルが知らない事を教えられる  ◦ 今日の天気は？  • LLMモデルにツールを使わせることができる  ◦ ファイルの操作  ◦ Githubの操作  LLMエージェントには必須の機能 

おすすめMCP  Github MCP • githubのほとんどの操作をLLM経由で実行可能。 • PRの自動修正もエージェントに任せることが
できる Context7 • 各ツールの最新ドキュメントをLLMに参照させることができる。

Github MCP x gemini code assist  PR作って  PR作成  コードレビュー  •
LLMモデルによって観点が異なる  • 異なるモデルで実装→1次レビュー  を行うことでより標準的で可読性の高いコードを作れる 

Github MCP x gemini code assist  PR修正して  レビューコメント収集   修正完了後 
再push 

Github MCP x gemini code assist  PR修正して  +修正できたら  レビュー依頼して  レビューコメント収集
  修正完了後  再push  再レビュー  • 自動でLLMがコード品質を高めてくれるループが完成！ 

生成AI疲れ個人の中のハイプ・サイクル    1. ちょっと試してLLMがすごい！という過度な期待。  2. 実際に使った幻滅  ◦ プロンプトが大変 
◦ 期待したアウトプットが出ない  ◦ レビューつらい  3. キャッチアップが面倒に(疲れ) 

生成AI疲れにならないように • いきなりLLMを本番開発に使おうとすると疲れる。  ◦ プロンプトの入力が大変。  ◦ 意図通りのアウトプットが出ずに結局手直し。  ◦ LLMの書いた大量のコードのレビュー  ◦
自己増殖する技術的負債  • 一番良いモデル(今だとClaude 4 opus)から使う  • コスパの良い使い方から始める 

コスパの良い使い方 • 小規模な開発補助ツール  ◦ メンテナンスする必要がない。数プロンプトでできることも  ◦ 数十行のシェルスクリプトなど  • デバッグ補助  
◦ デバッグコードのprint文を大量に差し込んでもらう。  • 大規模コードベースの解析  • PRの一次レビュー  • ドキュメンテーション  1. 人があまり介入しなくても良い  2. 動作確認する手間がかからない 

ドキュメンテーションの大事さ  • LLMエージェントはいつも新人  ◦ 新しいタスクのたびにコンテキストが0に戻る   ◦ 毎タスクごとに新人が担当するようなもの   •
生のコードを読ませるのは大変  ◦ コンテキストを食う、時間もお金もかかる   ◦ 要約したREADME.mdなどのドキュメントがコスト的にも時間的にも大事   • ドキュメントの執筆のコスト  ◦ ドキュメントもLLMに書かせることで執筆のコストが減る   • rules管理  ◦ コーディング規約やコミットメッセージなどの規約を明文化しておく   ◦ ai-doc-sync などを使って複数プラットフォームでruleを管理する  

スクラップ&ビルドを怖がらない • LLMだと急速に技術的負債がたまる    • 負債はトライアンドエラーを速く回すための借入(debt)という考え方  ◦ 意味のないプロダクトを綺麗に作っても仕方がない。  ◦ 意味のある/ないは実際に使ってみる(もらう)までわからない。 
◦ 負債(借入)をある程度許容して速く学習する。    • 負債の解消もLLMで速くできるようになっている。  ◦ (コストの問題もあるが)良い/悪いコードの審美眼があればLLMを使って負債を素早く解消することが可能に。    • LLMを簡単なところから使っていって慣れる。 

LLMで生産性が下がる？ • METRの研究では実はAIが生産性を落としていることが報告されている。  • 生産性が落ちているのにも関わらず被験者は生産性が上がったと錯覚していた。  タスクの見積もり  タスクの見積もり  手作業でかかった時間   AIを使ってかかった時間
  この差が19%増えた 

最後に、LLMとキャリア • LLMは本当に生産性(≠PR通過率)を高めてくれるのか  ◦ ある研究では実はAIが生産性を落としていることが報告されている。  ◦ 生産性が落ちているのにも関わらず被験者は生産性が上がったと錯覚していた。    •
当面は自分で書いた方が生産性が高い可能性  • LLMを使った開発が今後改善されていく可能性  • (自分のためにも、AIのためにも)開発者自身のスキルアップは必要  • LLMを用いた開発手法は継続的にキャッチアップする必要がある。 

(よかったらフォローしてください→) ご清聴ありがとうございました！

Appendix

v0.dev  • Vercel製のUI生成ツール  • 他のユーザーが作ったプロトタイプを使える  • Shadcn
+ Tailwind 構成でモダン  google AI studio  • 少ないプロンプトで綺麗なプロトタイプを作ってくれる。  • vite + reactのシンプルな構成で作ってくれる。  • GCPのCloud Runにデプロイ可能  プロトタイプ作成 

• 獣医の知人  • プログラミング経験皆無  ◦ エクセルですらさわれない   • 数時間で左のようなアプリ作成  •
動作確認が取りやすいアプリケーションならエンジニア要らなくなるんだろうなぁ...  Google AI Studio

生成AIツール大全 @ 2025

生成AIツール大全 @ 2025

More Decks by Umehara

Other Decks in Programming

Featured

Transcript