AIとどう付き合っていくか 2025春

AIとどう付き合っていくか 2025春

2025年春の時点の情勢をもとに、ソフトウェアエンジニアがAI技術とどう付き合っていくかという考え方の方向性について話してきました。

https://ssmjp.connpass.com/event/349539/

この記事では、その内容についてちょっとした補足を加えつつ紹介します。

サマリ (Claude Code)

2025年春時点でのLLM（大規模言語モデル）の現状と課題を整理し、ソフトウェアエンジニアがAI技術と効果的に付き合うための方向性を提示します。

LLMの3つの主要課題：

1. 計算の苦手さ - 数値計算やルール判定が不得意なため、MCPなど外部ツールとの連携が重要
2. 文脈の欠如 - 会話履歴、RAG、AIコーディングなどでコンテキストを適切に提供する必要性
3. 信頼性の問題 - 直接実行ではなく、手順を考えさせてコード化・レビューするプロセスが効果的

実践的なアプローチ：

• MCP（Model Context Protocol）を活用した外部ツール連携
• 日常的なAI対話によるコンテキスト蓄積
• エージェンティックワークフローによる業務自動化
• AIコーディングツール（Claude Code、GitHub Copilot等）の積極活用

「Always with AI」時代に向けて、AIの限界を理解しつつ適材適所で活用し、自分の「デジタル分身」を育てる考え方を提案しています。

前提・背景

• 2025年4月現在の情勢に基づいています
• 自分でさわった感触＋SNS（おもに𝕏）上の意見がベース

LLM(大規模言語モデル)のおさらいと課題

LLM(大規模言語モデル)とは、インターネットやその他のたくさんのデータを元に、なんやかんやして、機械学習した重み付けデータと、そのデータを使って推論をおこなうサービスです。

サービスとして普通の人がさわりはじめたのは2022年にChatGPTが登場してからで、まだたった2年半しか経っていません。

• 画像生成: Stable Diffusion (2022)
• OpenAI ChatGPT (2022) / GPT-4 (2023) / o1 (2024)
• 𝕏 Grok3 (2025)

LLMの核となっているのは、「次のトークンを予測する」という確率推定エンジンです。

LLMの課題

LLMが大きな価値を生み出すようになり、いくつかの課題がはっきりしてきました。

1. LLMは自分が計算機であることを忘れている
2. LLMは文脈を知らない
3. ルールに従わせることが容易でなく信頼できない

これからこの3点について考えていきます。

LLMは「自分が計算機であること」を忘れている

LLMは大規模言語モデルと呼ばれるように、様々な言語知識を元に「学習」が行われ、その学習結果をもとに言語を使って「推論」を行います。本来LLMを動かしているコンピューターも計算機であるはずですが、推論を行うプログラムでは特定の処理だけを「計算機の生の機能」を使った計算などをするようには実装されていません。そのため、「自分が計算機であることを忘れている」ように、数値計算が下手であったり、具体的なルールに厳格に従わせることが容易ではありません。

主要なLLMは「Transfomer」と呼ばれる技術をベースとしています。文字列をベクトルに変換したり重要な場所に注目したりしますが、突きつめれば「文章の続きを予測する」というアルゴリズムで動いています。これは文字の流れを見て「直感」だけで答えているようなもので、「9.11と9.9のどちらが大きいか」というLLMにとって苦手な問題がよく知られています。もちろん普通には9.9の方が大きいですが、プログラマであれば、バージョン番号という文脈だと9.11の方が新しかったりするという例も浮かぶかも知れません。

このように直感的な回答になりがちなLLMに複雑な推論をさせるには、いろいろ頑張らなくてはいけません。そのひとつの手法が、Chain-of-Thought(CoT)と呼ばれるテクニックです。「ステップバイステップで考えてください」と複雑なタスクを複数のステップに区切り、繰り返し考えてもらうことで、複雑な推論ができるようになります。

さらにこのCoTをベースにあらためてモデルを学習させることで、LLM単体でも複雑な推論ができるようにしたものが、Reasoning向けモデルと言われる、たとえばOpenAIのo1、o3のようなモデルです。

もちろんこのように「頑張ってもらう」ことで複雑な計算などもできますが、そもそも問題は、計算機がそれ自身の計算機能を直接使った計算をしていないことです。これでは、計算だけでは無くルールベースの○×判定のようなものも、大規模言語モデルのやり方で考えてしまうため「深く考えすぎてしまう」ことになります。

大規模言語モデルという「ことばを扱うしくみ」の上で苦労してやるよりも、そもそも「計算機」として素直に計算できる、LLMの「外」にある計算機やソフトウェアを上手く使ってもらう方が良いわけです。向いていない処理を無理やり頑張らせるのは、正確さに課題がある上に、計算コストの無駄遣いでもあります。

MCP

こういったことを解決するために、ReAct^[1]やFunction Callingなどいくつかのアプローチが登場しましたが、それらを経て現時点で一番注目を浴びているのがMCP^[2]という仕組みです。ほかにも、今回は取り上げませんが、AIエージェント間の通信にまつわるA2A(Agent2Agent Protocol)^[3]というものも登場しています。

MCPの正式名称は Model Context Protocol ですが、いったん名前の由来は忘れて構いません。MCPは外部からのデータ取得と、外部ツールの操作によく使われています。すでにたくさんのMCPサーバーの実装が存在しています。

https://modelcontextprotocol.io/introduction

• Model Context Protocol servers

• Awesome MCP Servers (日本語)

空前のMCPブーム

MCPの特徴は「どんなAPIを提供しているのか」をその中で伝えられる、自己言及的なメタプロトコルであることです。そのため、よくUSB-Cポートに例えられます。コネクタや電気的仕様までは決まっていても、中のプロトコルはUSBどころかThunderboltかもしれないし、通信しないPower Deliveryかもしれない、というところまで含めて上手い比喩です。

歴史の長いJSON-RPC 2.0ベースに基づいたプロトコルで、ローカルプロセス、リモートサービスどちらも想定されています。そもそも最初に登場したときの、LLMに手伝ってもらうことで簡単に自分で実装できる、というコンセプトからもわかるように、シンプルさが重要な要素です。

スキーマや名前空間がどうたら、と細かい仕様を決めておくのではなく、メソッド名とその説明、パラメータを定義しておけば、LLMが良い感じに選んで使ってくれるよ、という割り切りがあります。これは、UNIX哲学として知られる「ひとつの道具でひとつの機能を提供市、それらを組み合わせる」という考え方にも近いものです。

結局はRPC（Remote Procedure Call: リモート手続き呼び出し）と言うとおり、なんでもかんでもMCPでやろうと思いさえすれば提供できます。たとえば、Playwrightを使ったMCPをつくれば、ブラウザ操作ができ、LLMで動く「かしこいRPA」みたいなことを簡単に実現できます。

MCPでなんでも呼び出せるようになったら、次に考えるべきは、MCPでどのようなAPIを提供するべきか、が重要です。LLMに都度手順を考えさせることもできますが、やはりコンピューターサイエンスとしては、「抽象化された部品を使う」ということも考えていきたいところです。複雑なビジネスロジックのカプセル化や、権限の分離・隠蔽、といったことをあれこれ考えていくと、生のレベルのAPIでLLMに直接さわらせるよりも、そもそも 良いUI・API を提供した方が良いのではないでしょうか。

まさにMCPが使われ始めたばかりですが、これからこのあたりはどのような抽象化が好ましいのか、整理・整備が急速に進んでいくと予想しています。

LLMは文脈を知らない

LLM単体では状態を持たず(ステートレス)、プロンプトに書いていないことを知りません。（ただし、ChatGPTなどのサービスとしては、これまでの会話履歴などを文脈情報として積極的に共有するようになっています。ここではあくまで生身のLLMのことを指しています）

現実に仕事をするときのことを考えてみると、その前提となる文脈情報があります。たとえば組織の中にある仕様書や手順書、ビジネスモデル、個別の作業の目的や、作業者を取り巻く現在状況など、形式知であったり暗黙知だったりします。

これらをLLMにきちんと伝えてあげないと、価値が低い情報しか出てきませんし、ハルシネーションと呼ばれる誤判断を導きやすくなってしまいます。そこで「AIオンボーディング」と呼ばれるように、LLMがうまく推論するために必要な情報を与えることが重要です。

ChatGPT登場までは、このようなドメイン知識などを伝えるにはモデル自体を追加で学習するファインチューニングなどが必要でしたが、対話型(チャット形式)のインターフェースの会話の中で、判断材料をプロンプトの一部として伝える「コンテキスト内学習(In-Context Learning)」というやり方で上手くいくことがわかってきました。

つまり、どんな文脈(コンテキスト)なのかを適切に伝えることがとても重要です。

では文脈情報をどのようにプロンプトに含めるかを考えていきます。

会話履歴

一番分かりやすいのは、シンプルに会話の中に過去の会話のやりとりを含める方法です。そもそもLLM自体が、「そこまでの文章の続き」というものなので、自然な発想です。

例えば、以下のような会話履歴がある場合：

ユーザー: 来週のプレゼンテーション資料を作成したいのですが、どのような構成にすれば良いでしょうか？
AI: プレゼンテーションの目的と対象者を教えてください。それに応じて最適な構成を提案します。
ユーザー: 新しいマイクロサービスアーキテクチャの導入提案で、CTOと開発チームリーダー向けです。
AI: 技術的な詳細とビジネス価値を両立した構成をお勧めします...

このような過去のやりとりがあると、次に「先ほどのプレゼン資料にセキュリティの章を追加したい」と言うだけで、AIは文脈を理解して適切な提案ができるようになります。

直接会話した内容だけでなく、サービス提供者があらかじめAIにどのような振る舞いを期待するかを「システムプロンプト」として指示することも一般的です。そこにはサービス提供者の想いが詰め込まれています。 leaked-system-prompts として様々なサービスのシステムプロンプトを集めているサイトもあります（是非がありますのでリンクは張りません）。

またChatGPTなどのサービスでは、ひとつの会話だけでなく、他の会話履歴についてもヒストリとして読み込むようになっています。以下のような質問にも、会話履歴を元に分析して結果を返してくれます。

• 通常のGPT利用時の会話を通じて、私が囚われているバイアスやトラウマや呪いを発見し、メモリーに記録してください。また対話を通じて、私のバイアスや呪いをゆるやかに解体してください。
  • https://x.com/fladdict/status/1920940641380344008
• 私について、あなたが気づいているのに私自身はまだ気づいていない、驚くほど特別またはユニークな点を教えてください。必ずしもポジティブである必要はありませんし、私に優しくする必要もありません。ただ正直に答えてください。
  • https://x.com/mugu_KagawaAI/status/1916871296727847063
• 今までの自分との全ての過去会話のやり取りを通じて感じたことを元に、忖度せずに分析して客観的な意見をください。自分に「向いてない」ことは何ですか？
  • https://x.com/shields_pikes/status/1927900497283010747
• 私に関する各種メタデータと会話統計をすべて教えて。全期間を対象としてください。
  • https://x.com/super_bonochin/status/1914296124103643165
• 私の会話スタイルについて説明してください。好んで話す話題、やり取りのパターン、言語的な特徴、そして私と話してあなたがどう感じるかを含めてください。正確に述べてください。お世辞は不要です。
  • https://x.com/genkAIjokyo/status/1911206470907273419

つまり、日常的に利用すればしていくほど、文脈情報が自然に溜まって「自分向け」に調整されていきます。日々の疑問や、疑問への壁打ちをAIに質問していれば最近興味を持っていることがわかりますし、毎日のふりかえりを見てもらえば普段からの悩みをAIに覚えてもらうことができます。

RAGとMCP

プロンプト実行前に外部検索を行い、関連情報を取得してプロンプト内に組み込む手法がRAG（検索拡張生成: Retrieval-Augmented Generation）です。

たとえば以下のような資料をRAGによってLLMの文脈に取り入れることができます。

• 製品や組織内のドキュメント
• 最新の法改正情報
• 論文のサマリー
• 最新のニュース

大量のデータがあってもRAGでなんでもうまくいくかというと、検索自体が元来難しい技術であるという課題に直面します。雑に区切ってベクトルデータベースに入れるというのは2024年に幅広くためされましたが、より複雑な知識グラフに基づいて関連情報をたどったり、検索クエリ自体をLLMに生成させるといった、様々な試行錯誤が行われています。

簡単にRAGを使うために、NotebookLMやDifyのナレッジのようなオールインワンなサービスも増えてきました。

さらに、元々は文脈情報をモデルに提供するために設計されたMCP（Model Context Protocol）を用い、ローカルファイル、GitHubリポジトリ、データベース、BI環境など多様なデータソースから必要情報を取り込むのに使われています。

AIコーディング

文脈の与え方という点において、AIコーディングは現在最も進んでいる分野だと考えられます。GitHub CopilotやCursorといったツールは、既存のソースコード、設計思想、コーディングルールといった情報を効果的にLLMに与えることで、質の高いコードを生成します。

この分野では、技術的な意思決定の記録（ADRやDesign Docsなど）を明文化したり、開発に必要な情報を一元管理（Single Source of Truth）したりすることの重要性が増しています。

AIが生成したコードを使うのは、いわば「コピー＆ペースト 2.0」に過ぎない側面もあります。これはLLMによる生成結果が何かのコピーだということではなく、生成されたコードをどうやって取り入れるか、という視点が重要です。

単に必要なコードをそこに書いてもらうだけでなく、ソフトウェア全体のシステム工学として全体を設計し、ベストプラクティスにもとづいて適切にライブラリ化し、そのライブラリをLLMに使わせるというサイクルを構築することが、今後の発展において重要になります。

もう少し先の話としては、AIコーディングとオープンソースソフトウェアという観点にも注目があつまるでしょう。

自分の行動データ

AIが常時接続する時代が間もなく到来します。これは、SF作品で描かれる「電脳化」のように、人間の脳がAIを介して外部世界の知識と連携していく未来とも言えます。

いつでもどこでも「電脳化」された知能との対話・連携が当たり前になると、実世界での行動や結果が、継続的にAIに流れ込みアップデートされます。日々の対話を通じてLLMにコンテキストを蓄積させることで、いわば「自分の分身」を育て、意思決定を委ねる「デジタルクローン」のような存在も、2〜3年後には現実味を帯びてくるかもしれません。

もちろん、そのためにはデータガバナンスやプライバシーの課題を克服する必要があります。Apple社のようにデバイスとクラウドのハイブリッドでプライバシー保護を目指すアプローチや、GDPR（EU）と中国のようなデータ活用に対する思想的な対立も存在します。

よりみち：集中と分散と電力

ここでちょっとよりみちをします。

LLMの規模の問題は、集中と分散と電力の問題に行き着きます。デバイス上で動作する小規模言語モデル（SLM）の発展には期待が寄せられていますが、現時点では性能的に限界があり、当面はクラウド上の高性能なLLMに頼らざるを得ない状況が続くでしょう。

そのクラウド側も安泰ではありません。
現在はNVIDIA製チップへの需要集中により、チップをより多く集めたサービスに供給能力が集中しています。さらにGPU側のインターコネクト速度やメモリ帯域が極めて重要なので、1ラックにより多くの計算機資源を集中させる必要があり、直接液冷技術などを前提としたAIデータセンターが2024年ごろから実用ベースに乗ってきています。
さらに利用者からのリクエストに比例するAI推論のための電力量は、太陽光発電などとの相性が悪いという問題もあります。雨の日はAI使わないで、とは言えないですからね。
これが複数の国で分散できるメガクラウドであればマルチリージョンでの解決という手もありますが、日本国内の事業者や法律等の事情でデータ保存先に制限がある場合など、カーボンニュートラル的価値観とのバランスを見ていく必要があるかも知れません。たとえばソフトバンクグループが将来的に原子力発電所1基分に相当する電力供給（最終的に1GW）^[4]を計画しているように、日本の消費電力が不足するのではないかという懸念も生じてきています。

明るいニュースとしては、LLMのアルゴリズムの改善はとんでもない速度で進んでいます。最近では3ヶ月で同じ性能で必要とするモデルサイズが半分というペースで、今はクラウド側の巨大GPUクラスターでなければ動かせないモデルと同じ性能が、来年には個人でも入手できるGPU上で動くようになりそうです。そう考えると、GPUのチップ取り合いがボトルネックという状況はすぐに変わり、世界のAI需要と電力供給量の競い合いになります。

ルールに従わせることが容易でなく信頼できない

無限にも等しい知識を持っているなら、頑張れば何でもできそうですが、現実の問題を解いてもらうには意外と色々な事が苦手です。

LLMになにをさせるのか

LLMに何をさせるべきかを考えていくと、日々の業務に取り入れるだけでなく、AIを組み込んだサービスとして提供することが考えられます。

• 営業支援
• 人では面倒くさかった（人件費に見合わない）細かい管理
• 文脈を踏まえたインサイト発見、不正検知
• 新入社員のオンボーディング（研修）、相談相手
• レガシー機器のDX（メーターをカメラで数値データ化）

正確性・再現性の担保

LLMとSaaSは、ある意味で競合する関係にあります。様々なドメイン知識に基づいてSaaSが提供する機能は、突き詰めればLLMでも実現可能ではないか、という見方ができるからです。しかし、業務で利用するには正確性や再現性が不可欠です。
そのため、LLMには「手順を考えてもらう」役割を担わせ、その実行は「コンピュータに任せる」という分業が効果的です。

問題を直接解かせるのではなく、問題を解くための使い捨てコードを生成し、それを外部ツールとして実行します。ここでもMCPを利用したツール利用が有用です。
たとえばクラウドであれば、MCP経由で取得した構成情報を元に、IaC（Infrastructure as Code; TerraformやAWS CDK）のコードを生成してもらいます（AIにとってもIaCは「基本的人権」と言えるでしょう）。
人も間違えるしAIも間違えますが、一度「コード」の形になってくれれば、それを人間がレビューできますし、別のLLMによって「LLM-as-a-Judge」してもらえるようになるのも時間の問題でしょう。

この考え方は、実世界の情報をデジタル空間に再現する「デジタルツイン」とAIを組み合わせる際にも重要になります。トラック（に積まれた荷物）の移動履歴による物流の最適化や、ドローンで撮影した点群情報から土砂崩れの予測など、IoTの文脈もAIにどんどん接続されていきます。
ここでも上がってくるデータひとつひとつに対してLLMでじっくり考えるのでは無く、LLMに判断ルールを書いてもらい、自動化してもらうのが現実的です。またポイントは粒度が重要ということで、キャベツを数えるのに分子レベルのシミュレーションは不要です。

AIワークフロー

そもそもあらゆる仕事には手順、すなわちワークフローが存在します。このワークフローの構築をLLMに推論させるのが「エージェンティックワークフロー」という考え方です。

論理的推論や厳密な計算、ドメイン知識に基づくルールの遵守などをLLMに直接実行させるのは、頑張れば決して不可能では無いとは言え、判断の安定性やコストの観点からも得策ではありません。人もAIも間違えることがある、ということを思い出してください。
そこで、膨大な法律や商慣習などの知識を基にLLMにワークフロー（すなわち一種のコード）を構築させ、人間がその正しさをレビュー・監査します。そして、そのワークフローを定型化（コード化）していく。この流れは、先述したAIコーディングに行き着くと考えられます。

ここでもやはり、AIによる自律判断と、AIが書いたコードによる型化、というバランスが重要となります。これはAIの新しい問題ではなく、担当者が抱えた暗黙知を、様々な手順書をおこし、形式知にまとめていくのと同じ事です。

こうやって作り上げた「信頼できる形式知」でもあるコードは、さらにその次の新しい事を考えるときの文脈情報にもなっていきます。

AIと生きていく

現状のLLMベースのAIについて、いくつかの課題を紹介しました。

1. LLMは計算が苦手なので、コードを書かせてソフトウェアに実行させる。
2. LLMは文脈を知らないので、対話を通じてコンテキストを育てる。
3. LLMには、解き方を考えさせ、コード化・レビューするプロセスを担ってもらう。

こういったことを踏まえつつ、AIに自分の思考、意志を食わせ、自分の半身を育てるために、日記、ふりかえりといったものを日常的に会話すると、LLMがぶっちゃけどれくらいの性能なのかという体験にもなります。ChatGPTとの会話履歴や、最近話題になっているObsidianなどテキストフレンドリーなメモ基盤などが役に立つでしょう。

さらに、Claude CodeなどAIコーディングや、エージェンティックワークフローなど、AIに使わせる道具を数多く用意しておくのも、MCPがまさにブームとなっている今だからこそ是非さわってみるのをおすすめします。

もう間もなく「Always with AI」の時代になります、楽しんでいこう！

脚注

1. Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., & Cao, Y. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. Proceedings of the 11th International Conference on Learning Representations (ICLR 2023). https://arxiv.org/abs/2210.03629

2. Model Context Protocol (MCP) https://modelcontextprotocol.io/

3. Agent2Agent (A2A) Protocol https://github.com/google-a2a/A2A

4. https://www.asahi.com/articles/AST4H3QDQT4HIIPE007M.html