AIの最新動向、実際に追ってみて思うこと——流行に振り回されないための現場視点
はじめに——「また新しいモデルが出た」に疲れていませんか
最近、AIのニュースを追うだけで一日が終わってしまいそうになることがあります。
「GPT-4oが出た」「Claudeがすごいらしい」「Geminiも進化した」「オープンソースのLlamaが追い上げている」——こうした情報が毎週のように飛び込んできて、正直なところ、少し疲れを感じている方も多いのではないでしょうか。
私自身、AIエンジニアとして長く仕事をしてきましたが、ここ1〜2年の変化のスピードは異常だと感じています。追いかけるだけで精一杯、というのが本音です。
ただ、だからこそ思うのは、すべてを追う必要はないということ。そして、流行と実用は違うということです。
この記事では、2024年現在のAI動向について、私なりの整理をしてみたいと思います。網羅的なニュースまとめではなく、「実際に使ってみてどうだったか」「現場から見てどう評価しているか」という視点で書いていきます。
技術的に深い話もありますが、できるだけ噛み砕いて説明するつもりです。AIに興味はあるけど専門家ではない、という方にも読んでいただけたら嬉しいです。
大規模言語モデル（LLM）の現在地——「すごい」から「どう使うか」へ
ChatGPTの登場から約2年、何が変わったか
2022年11月にChatGPTが公開されてから、もう2年近くが経ちました。当時の衝撃を覚えている方も多いと思います。私も最初に触ったときは「これは仕事の仕方が変わるな」と直感しました。
あれから何が変わったかというと、モデルの性能向上と選択肢の増加、この2つが大きいと思います。
まず性能について。GPT-4が出たあたりから、「文章を生成する」だけでなく、「論理的に考える」「複雑な指示を理解する」という能力が格段に上がりました。最近のGPT-4oやClaude 3.5 Sonnet、Gemini 1.5 Proあたりは、ちょっとした調査や分析なら人間の補助として十分に使えるレベルです。
次に選択肢について。以前はOpenAI一強という雰囲気がありましたが、今はAnthropicのClaude、GoogleのGemini、Metaが公開しているLlama、そしてMistralやCohere、日本だとPreferred Networksなど、様々なプレイヤーが参入しています。
これは良いことでもあり、悩ましいことでもあります。「どれを使えばいいんだ」という問題が出てきたからです。
正直なところ、モデルの違いはどこまで重要か
私の感覚では、トップクラスのモデル同士の差は、思ったほど大きくないというのが正直なところです。
GPT-4o、Claude 3.5 Sonnet、Gemini 1.5 Pro——どれも十分に賢いです。もちろん得意・不得意はあります。Claudeは長文の処理や指示への忠実さに定評がありますし、Geminiは大量のコンテキスト（入力テキスト）を扱えるのが強みです。GPT-4oはマルチモーダル（テキスト、画像、音声などを統合的に扱う能力）のバランスが良い印象があります。
でも、実務で使う分には、どれを選んでも「まあ使える」というのが実感です。むしろ重要なのは、どのモデルを使うかよりも、どうプロンプトを設計するか、どうシステムに組み込むかだと思っています。
モデル選定に何週間もかけるよりも、実際にプロダクトに組み込んで検証するほうが学びが大きいです。私のチームでも、最初は「最強のモデルを見極めよう」と意気込んでいたのですが、途中から「とりあえず動くものを作って、あとで切り替えられるようにしておこう」という方針に変わりました。
オープンソースモデルの台頭——Llamaの衝撃
ここ1年で大きかったのは、MetaがLlamaシリーズをオープンに公開したことです。Llama 2、そしてLlama 3と進化してきて、性能もかなり上がっています。
何がすごいかというと、自分たちでモデルをホスティングできるという点です。OpenAIやAnthropicのAPIを使う場合、データを外部に送ることになります。セキュリティやプライバシーの観点で、それが難しい業界や案件もあります。
Llamaのようなオープンモデルなら、自社のサーバーやクラウド環境で動かせます。もちろん、そのための計算リソース（主にGPU）は必要ですが、選択肢が増えたことの意味は大きいです。
私も実際にLlama 3の70Bモデル（パラメータ数が700億のモデル）を試してみましたが、「これで十分なユースケースは多いな」という印象でした。もちろんGPT-4oほどではないですが、社内ツールや特定のタスクに絞った用途なら十分実用的です。
マルチモーダルAIの進化——テキストだけじゃなくなってきた
画像、音声、動画……扱えるものが増えている
「マルチモーダル」という言葉を最近よく聞くようになりました。これは、テキストだけでなく、画像や音声、動画など複数の種類のデータを扱えるAIのことを指します。
GPT-4Vが画像を理解できるようになったあたりから、この流れは加速しています。今では、画像を見せて「これは何？」と聞いたり、グラフを読み取らせたり、手書きのメモをテキスト化したり、といったことが普通にできるようになりました。
GoogleのGeminiは、最初からマルチモーダルを前提に設計されていると言われていて、長い動画の内容を理解するようなデモも公開されています。
私が最近試して「これは便利だな」と思ったのは、設計図やワイヤーフレームを読み取らせるという使い方です。手書きのラフをスマホで撮影して、「これをHTMLにして」と頼むと、それなりのコードが出てきます。精度は完璧ではないですが、たたき台としては十分です。
音声AIの進化——リアルタイム会話が現実に
音声の分野でも進化が著しいです。OpenAIが発表したGPT-4oの音声機能は、かなりのインパクトがありました。遅延がほとんどなく、自然な会話ができる。感情を込めた話し方もできる。映画に出てくるAIアシスタントに近づいてきた感じがします。
音声認識（Speech-to-Text）の精度も上がっています。OpenAIのWhisperは、日本語の認識精度もかなり高く、議事録作成や文字起こしの実務でも使えるレベルです。私のチームでも、社内ミーティングの文字起こしにWhisperベースのツールを導入しましたが、以前使っていた有料サービスより精度が良いくらいでした。
動画生成——Soraの衝撃と、まだ見えない実用
OpenAIが発表したSoraは、テキストから動画を生成するモデルです。デモ映像を見たときは、正直驚きました。映画のワンシーンのような動画が、テキスト指示だけで生成される。これは本当に革命的だと思いました。
ただ、現時点ではまだ一般公開されていませんし、仮に公開されても、すぐに実務で使えるかというと、そこは慎重に見ています。
動画生成は計算コストが非常に高いですし、著作権や肖像権の問題、フェイク動画への懸念など、社会的な課題も山積みです。技術としては素晴らしいですが、「仕事で使う」となると、もう少し時間がかかるだろうというのが私の見立てです。
AIエージェントという概念——自律的に動くAIへの期待と懸念
エージェントとは何か
最近、「AIエージェント」という言葉をよく聞くようになりました。これは、単に質問に答えるだけでなく、自分で計画を立てて、タスクを実行するAIのことを指します。
例えば、「来週の出張の手配をして」と頼むと、AIが自分でフライトを検索し、ホテルを予約し、スケジュールをカレンダーに入れる——そんなイメージです。
この分野では、AutoGPTやBabyAGIといった実験的なプロジェクトが話題になりましたし、最近ではAnthropicがClaude向けにツール利用機能を強化したり、OpenAIがAssistants APIを提供したりと、各社が力を入れています。
実際に試してみた感想
私もいくつかエージェント的なシステムを試作してみました。正直な感想を言うと、まだ実用には遠いというのが率直なところです。
単純なタスクなら動きます。例えば、「このURLの内容を要約して、Slackに投稿して」くらいなら、そこそこ動く。でも、複雑なタスクになると、途中で間違った判断をしたり、無限ループに陥ったり、予想外の動きをしたりします。
特に難しいのは、失敗したときのリカバリーです。人間なら「あ、これは違うな」と気づいて軌道修正できますが、現状のAIエージェントはそれが苦手です。一度間違った方向に進むと、そのまま突き進んでしまうことが多い。
だから、今の段階では「完全に任せる」のではなく、「人間の監視のもとで、部分的に自動化する」くらいが現実的だと思っています。
期待しすぎず、でも注視はしておく
AIエージェントに関しては、過度な期待は禁物だと思っています。「もうすぐAIが全部やってくれる」みたいな話は、少なくとも今の技術水準では難しい。
ただ、この分野の進化は速いので、1年後にはまた状況が変わっているかもしれません。私としては、「今すぐ本番投入」ではなく、「実験的に触っておいて、技術の限界と可能性を理解しておく」というスタンスで見ています。
RAGとファインチューニング——自社データをどう活かすか
二つのアプローチ
企業でAIを使おうとすると、必ず出てくるのが「自社のデータを使いたい」という要望です。汎用的なAIではなく、自社の製品や業務に特化した回答をしてほしい、というわけです。
これを実現する方法として、大きく二つのアプローチがあります。
一つはRAG（Retrieval-Augmented Generation）。これは、質問に関連する情報をデータベースから検索して、それをAIに渡して回答を生成させる方法です。モデル自体は変えずに、「参考資料を渡す」イメージですね。
もう一つはファインチューニング。これは、自社のデータを使ってモデルを追加学習させる方法です。モデルの「知識」自体を書き換えるイメージです。
実務での使い分け
私の経験では、多くのケースでRAGから始めるのが良いと思っています。
理由はいくつかあります。まず、RAGのほうが圧倒的に手軽です。ファインチューニングは、データの準備や学習環境の構築など、それなりの手間とコストがかかります。RAGなら、既存のドキュメントを検索可能な形にして、それをプロンプトに含めるだけで、ある程度の効果が得られます。
また、RAGは情報の更新が容易です。新しいドキュメントが追加されたら、それを検索対象に加えるだけ。ファインチューニングだと、データが変わるたびに再学習が必要になります。
じゃあファインチューニングは不要かというと、そうでもありません。特定の文体やトーンで回答させたい場合や、特殊な形式の出力が必要な場合は、ファインチューニングのほうが効果的なこともあります。
私のチームでは、まずRAGで試して、それで不十分な部分があればファインチューニングを検討する、という順番で進めることが多いです。
RAGを試してみてわかったこと
実際にRAGを導入してみて、いくつか気づいたことがあります。
一つは、検索の精度がとても重要だということ。いくらAIが賢くても、渡される情報が的外れだと、良い回答は生成できません。だから、ベクトル検索（文章の意味的な類似性で検索する方法）の精度を上げたり、メタデータでフィルタリングしたり、といった地道な工夫が必要になります。
もう一つは、チャンク分割の設計が意外と難しいということ。長いドキュメントを検索対象にするとき、どう分割するかで結果が大きく変わります。細かすぎると文脈が失われるし、大きすぎると関係ない情報が混ざる。この「ちょうどいい」を見つけるのに、けっこう試行錯誤しました。
コード生成AIの進化——GitHub Copilotから先へ
開発者の日常に溶け込んできた
プログラマーにとって、コード生成AIはもう身近な存在になってきたのではないでしょうか。
GitHub Copilotが登場して約2年。私も毎日のように使っていますが、生産性は確実に上がったと感じています。特に、定型的なコードを書くとき、ボイラープレート（お決まりの記述）を自動補完してくれるのは本当に助かります。
最近はさらに進化して、Claude for Devや、Cursor、Codeiumといった競合も出てきました。それぞれ特徴がありますが、総じて「コードを書く」という作業の支援ツールとしては、かなり実用的になってきたと思います。
便利だけど、任せきりにはしない
ただ、私は「AIにコードを任せきりにする」ことには慎重です。
AIが生成するコードは、一見動くように見えても、エッジケース（例外的なケース）を考慮していなかったり、セキュリティ上の問題があったりすることがあります。特に、ライブラリの使い方が古かったり、存在しないAPIを自信満々に書いてきたりすることもあります（これを「ハルシネーション」と呼びます）。
だから、AIが生成したコードは必ずレビューする、という姿勢が大事だと思っています。「参考にはするけど、最終判断は自分でする」というスタンスですね。
チームのジュニアエンジニアには、「Copilotの提案をそのまま採用する前に、なぜこのコードで動くのか、自分で説明できるようにしてね」と伝えています。便利なツールに頼りすぎると、基礎的な力が育たなくなる懸念もあるので。
AIの安全性と規制——無視できない話題
急速に進む議論
技術の進化と並行して、AIの安全性や規制に関する議論も活発になっています。
EUでは「AI Act」が成立し、リスクベースの規制が導入されました。アメリカでも大統領令でAIの安全性に関するガイドラインが示されましたし、日本でも「AI事業者ガイドライン」が策定されています。
これは、AIを業務で使う側としても、無視できない話題です。特に、顧客データを扱うようなシステムにAIを組み込む場合、プライバシーや説明責任の問題は避けて通れません。
実務で気をつけていること
私のチームでは、AIを使ったシステムを開発する際に、いくつかのルールを設けています。
まず、入力データの取り扱いを明確にすること。ユーザーが入力したデータがどこに送られるのか、保存されるのか、学習に使われるのか、これを明確にしておく。外部APIを使う場合は、そのAPIの利用規約やプライバシーポリシーも確認します。
次に、AIの出力を最終判断にしないこと。特に、法的な判断や医療に関わる内容、人事評価など、重要な意思決定には、AIの出力をそのまま使わない。あくまで「参考情報」として扱い、最終判断は人間が行う設計にしています。
あとは、ログを取っておくこと。AIが何を入力として受け取り、何を出力したか。問題が起きたときに追跡できるようにしています。
このあたりは、まだ業界としてベストプラクティスが固まっていない部分も多いです。私たちも試行錯誤しながら、都度見直しています。
これからのAIとの付き合い方——私が意識していること
流行を追いすぎない
冒頭にも書きましたが、AIの世界は変化が速すぎて、すべてを追うのは不可能です。
私は最近、意識的に「すべてを追わない」ようにしています。新しいモデルが出たら一応チェックはしますが、すぐに飛びつくことはしません。少し待って、評価が定まってから触ることが多いです。
どうしても新しいものを試したくなる気持ちはわかります。でも、本番システムで使うなら、安定性や継続性も大事です。「最新」よりも「信頼できる」を重視するようにしています。
基礎を大事にする
AIツールが便利になればなるほど、逆に基礎的な技術力の重要性が増すと感じています。
AIが生成したコードをレビューするには、そのコードを理解する力が必要です。AIの出力が正しいかどうか判断するには、そのドメインの知識が必要です。AIを効果的に使うには、プロンプトエンジニアリングの知見も必要ですが、それ以前に「何をさせたいのか」を明確に言語化する力が必要です。
結局、AIは道具であって、使う側の能力が問われるんですよね。これは、ExcelやGitが登場したときと同じだと思います。道具が進化しても、基礎ができている人は適応が速い。
正直に「わからない」と言う
AIについて聞かれることが増えましたが、私は「わからない」と言うことを恐れないようにしています。
正直、この分野は専門家でも予測が難しいです。「来年はこうなる」なんて、誰にもわからない。だから、知ったかぶりをするよりも、「今の時点ではこう理解している」「ここはまだ試行錯誤中」と正直に伝えるようにしています。
この記事も、1年後に読み返したら「古いな」と思う部分があるかもしれません。それは仕方のないことだと思っています。
おわりに——変化の時代に、地に足をつけて
長くなりましたが、ここまで読んでいただきありがとうございます。
AIの最新動向について、私なりの視点でまとめてみました。網羅的ではないですし、偏りもあると思います。でも、「実際に使っている人がどう見ているか」という一つの参考になれば嬉しいです。
私が今、大事だと思っているのは、変化に振り回されないことです。新しい技術が出るたびに右往左往するのではなく、自分たちの課題を明確にして、それを解決するためにAIをどう使うか、という順番で考える。
AIはあくまで手段です。「AIを使うこと」が目的になってしまうと、本末転倒になります。
もちろん、技術のキャッチアップは必要です。でも、それと同時に、基礎的な技術力を磨くこと、ビジネスの課題を理解すること、チームで協力すること——そういう「変わらない大事なこと」も忘れないようにしたいと思っています。
皆さんは、今のAIの状況をどう見ていますか？ 業務でどう使っていますか？ もし機会があれば、そんな話もできたら嬉しいです。
これからも、流行に振り回されず、でも新しいものへの好奇心は忘れず、地に足をつけて技術と向き合っていきたいと思います。
