Go to Qiita Advent Calendar Top
LoginSignup
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Day 1

ひとりアドカレ | 2025に学んだことの振り返り Advent Calendar 2025

@benjuwan

AI全盛の世界で人間側の差別化要素となるもの

Last updated at Posted at 2025-12-02

これは、筆者の「2025振り返り用ひとりアドカレ」記事の一つです。

概要

本記事は、極力無料主義な筆者が業務や個人開発などを通じて得た「AI利活用に関する所感および情報をまとめたドキュメント」になります。

所感や知見を、その時々の記事にまとめていたのですが、散らばってきた感が出てきたので一つの記事にまとめようと思いました。

現段階（2025/12）での生成AI（LLM）利活用における筆者の結論としては、 AIが進化するほど以下の内容が人間側の差別化要素となるという考えです。

  • 設計力
  • 問題把握・想起力
  • 論理的思考に基づく言語化能力
  • 抽象・具体の柔軟な思考切り替え

はじめに

生成AI（LLM）は、設計、開発、情報整理など幅広い分野で活用されています。

特に近年では Vibe Coding や仕様駆動開発、AI駆動開発といった、AIが自律的に支援・主導するスタイルが注目されています。

Vibe Coding
AIがコードを自動生成し、開発者は自然言語で指示を出すだけで開発できる手法を指す

現状の業界トレンドとして、Claudeなど各種AI（LLM）を最良活用するためにユーザー（開発者）の目的とする成果物を生成できるようなルール設定を試行錯誤し合っている状況だと感じています。

AGENTS.md, copilot-instructions.mdなどのメタ設定ファイルは、AIに人間側の意図を汲み取らせるためのレールであり、最適なレールの敷き方（ベストプラクティス）を模索している段階にあるとも思っています。

こうした流れの中で筆者は次のように感じています。

  • コード実装力や実装速度よりも、設計力など上流工程に関するスキルが重要になってくる
  • AIの成果物をチェックするための（言語や仕様、フレームワーク、ライブラリなど）基礎知識
  • 基礎知識に基づく（専門用語を盛り込むなどの）適切なプロンプトをつくるための言語化能力と論理的思考力
  • 抽象・具体の柔軟な思考切り替え
    • 抽象化能力：課題や情報、概念、アイデアといった取り組む対象の本質を捉えるために必要
    • 具体化能力：本質を言語化したり、根本的解決の直接的・間接的要因を閃いたり、具体的なアプローチ方法に落とし込んだりするために必要
余談

筆者は極力無料主義なので、汎用化かつ拡張された無料AIツールの到来を期待しつつ、その時が来れば十分に活用できるよう情報収集と慣れを重ねておくべきとも考えています。

これは「現状、AIに関する形式知と暗黙知を蓄積する戦略を採っていきたい」という考えがあり、（自分たちにとって）適切な使用イメージを掴むためには汎用性のある知見（形式知と暗黙知）の充実が大事になってくると思っているためです。

例えば、「パソコン（またはスマホ）を使って何かして」と言われれば現代人は調べ物をしたり、資料作成など仕事に用いたりするといった使用イメージを苦もなく描けるはずです。
その理由は、多くの人がデジタルデバイスの利用が当たり前となって形式知と暗黙知が充分にあるからです。

この点はAIも同じだと思います。

そして、この先は ものごと（例：未知の課題やビジネスアイデアなど）へのアプローチを考える「問題把握力と問題想起力」がより重要 となるのでは？と考えています。

人と人とのコミュニケーションが必要な部分以外においては、課題解決力など実務面はAIが担っていくと考えられるので、人はものごと及びそれへのアプローチを考える役割が強くなりそうだと。
先に述べた問題把握力と問題想起力とは、課題解決における方針や仮説出し、アプローチ方法の選定など上流工程部分に関わってくるようなもの、と想定しています。

具体的には以下です。

  • 問題把握力
    どこにどんな問題があるかのアタリを付ける（仮説を出してアプローチ範囲を設定する）
  • 問題想起力
    何がペインまたはボトルネックかを考える

上記のような「問題の切り分け方法」といったエンジニアリング以外に関する事柄については以下の記事が参照になりました。

そして、今後スタンダードとなるAIを活用した働き方（AIとの協業）においては、以下の「基礎知識」と「AI活用の知見」が重要となると考えています。

例えば、これまでの「Pythonを学ぶ」や「Nextを使ってトレンドに追従」という基礎学習となる部分に加えて、AI活用の学習が必要となるので学ぶ量が倍増すると思いますorz。

  • 基礎知識
    • サイトが表示される仕組みや通信などWeb・インターネットに関する土台となるような部分
    • JavaScript（TypeScript）, Python, Go, PHP といった言語
    • React/Next, Vue/Nuxt, Django, Flask , Laravel などのフレームワークの学習
    • AIが生成したコードの安全性をチェックするためのセキュリティ関連の知識
  • AI活用の知見
    • プロンプトエンジニアリング
    • 各種生成AI（LLM）の特徴（例えば、検索系はPerplexityとか）
    • MCP, A2A, Vibe Coding, SDD などトレンドのキャッチアップ
    • 他者や他企業の活用事例（Tips）の収集と、自身や自社への還元方法の想起など

AI駆動開発と協業のポイント

AIとの協働においては、設計力・伝達力・段階的進行の3つがポイントになります。

具体的に言うと、人間が設計を主導し、適切な粒度で要件をAIに伝える。AIはそれに基づいて自分たち（AI）が理解しやすい形でタスクを定義および実施する という「明確に役割分担された協業スタイル」を指します。

AIにとって曖昧な部分を残さず、具体的・逐次的に伝えることが作業効率および成果物の信頼性向上につながります。

以下詳細です。

設計力：ゴールと構造を明確に描く

  • ゴール・要件・制約を明確に伝える
    • プロジェクト・実装機能の目的や背景情報（なぜこの機能が欲しいのか、最終的にどうしたいのか、どうなってほしいのか）
      • 例：「PDF/Excel/画像も対象」「AIで画像内容も判定」「拡張性重視」など
  • 設計思想や重視したい観点を伝える
    • 「疎結合」「責務分離」「保守性」「初学者向けコメント」など、重視したいポイントを明示
      • 適切な専門用語を用いてAIと明確なコミュニケーションを図る

伝達力：情報共有と文脈の維持

  • プロジェクト構造やファイル内容を逐次共有
    • 全体把握をはじめ、開発者（ユーザー）が修正・変更などした更新箇所をAIに伝えて随時確認してもらう（フェーズを設ける）
  • プロジェクトまたはファイルの全体像を把握してもらって、プロジェクト・実装機能の目的や背景情報を十分理解してもらう
    • ※もし前提条件（要件）が変わった場合は随時伝える
    • ※長時間のやり取りやファイル量が増えると記憶の限界に達するので、適宜AI側にプロジェクトの目的を再確認してもらうフェーズを設ける
      • 例：「前にも出したこの設定ファイルを再掲します」「改めて全体構造を整理します」など
  • 変更点や新規ファイルも都度明示
    • 開発者（ユーザー）が修正・変更などした更新箇所をAIに伝えて随時確認してもらう（フェーズを設ける）
    • 上記AIへの更新確認フェーズとともに関連ドキュメント（READMEや設計、仕様書など）の内容もAIにアップデート（更新）してもらう
  • エラーや実行結果は全文渡す
    • ログに出たエラー情報やターミナル出力は省略せず、全文をAIに見せる（AIに伝える際、エラー内容は極力省略しない）

段階的進行：ステップごとの合意形成

  • 「この段階で一度確認」「OKなら次へ」と段階的に進行
    • 開発者への確認フェーズ（確認 → Goサイン → タスク実施）を必ず設ける
  • 指示は明確に、細粒度なタスク依頼を行う。加えて、AIとの意思疎通を意識した進捗管理を行う
  • 「ステップバイステップで……」という文言を随時入れてAI自身に思考過程を設けた上で作業を進めてもらう
  • AIが「この方針で進めてよいか？」と聞いてきたら、必ず明確に返答する
    • 開発者への確認フェーズでAIが提案してきた実装内容・方針を把握しておくことで、ズレがないかチェックできたり、プロジェクト管理しやすくなったりするメリットがある

その他

  • 出力結果は文法的に正しくても、仕様的に誤っていたり、前提にズレがあることもある
  • 特にコード生成やAPI設計では「合っているように見えて誤り」が起きやすいため、人間側で必ずレビューを行う

これらに加えて、AIとのやりとりでは、論理的思考に基づく言語化能力が不可欠です。
AIには非言語的（ノンバーバル）な意図は伝わらないため、人間が構造的に考え、明確に伝える力が必要です。
このスキルはプロンプトエンジニアリングの中核であり、他にも応用が利く汎用的能力になると感じています。

ポイントまとめ

  • AIと人間の協働開発は「プロジェクト構造・ファイル内容など情報共有」と「段階的な進行」がカギ
  • AIは「明確なゴール（＝何がしたいのか）」「全体像」「具体的なエラー情報」があると最大限力を発揮できる
  • タスク依頼時は、細かな粒度で具体的に指示
  • 設計思想（疎結合・責務分離など）の共有
  • 適切な専門用語を用いてAIと明確なコミュニケーションを図る

AIにとって理解しやすい構造と段階的な進行を維持することで、誤解を減らし、再現性を高められます。

Vibe Coding（雰囲気コーディング）の活用と課題

AIが自律的に高速コーディングしているときに、AIが同じエラーを繰り返す「pit of death」という現象も起こり得ます。

pit of deathを減らすには

  • タスクのスコープを狭める（タスク粒度の最適化）
  • 1つのタスクあたりのステップ数を少なくする
  • 生成の特性を知る
    • 現時点のAIは既存内容の修正が苦手で、基本的にスクラップ・アンド・ビルドのような生成の仕方（0→1）をするので、ケース・バイ・ケースでプロンプトの内容や実装方針を変えてみたりする。

MCP（Model Context Protocol）について

MCPとは、生成AIと外部サービスをつなぐ共通プロトコルです。
AIが外部ツール・API・ファイルシステムなどと連携し、文脈を理解した上で自律的に処理を行えます。
これにより、チャットベースのやりとりを超えた 「行動できるAI」 が実現します。

MCPの構成と動作概要

MCPホスト, MCPクライアントが「操作指示窓口」で、MCPサーバーが「外部サービスとの連携に必要な中継点」というイメージです。

Host

複数のMCPクライアントを統括・管理する中核。
Claude Desktopなどが該当し、MCPの中でAIの行動環境をホストする役割を担います。

Client

人間の入力や操作を受け取り、AIモデルとの橋渡しを行う層。
リモコン的な役割であり、ユーザー指示をMCPサーバーに中継します。

Server

外部リソース（GitHub、Figma、DB、APIなど）へのアクセスを提供。
AIはこのサーバーを介して、必要なデータを取得・操作できます。
サーバーはCLI経由で立ち上げられます。

ちなみに、MCPサーバーにはtoolという「そのMCPサーバーが提供する処理リスト」のようなものがあります。
端的に説明すると、「自分（MCPサーバー）はこんな機能を持っています」とMCPサーバーが情報提供していて、 もし気になるものがあれば「エージェント（MCPクライアント）にそのMCPサーバーを登録して使ってみる」といったものになります。

toolについて 
server.tool(
  // 第1引数 : MCP経由でAIやクライアントがこのツールを呼び出すときに使う名前
  "get-alerts",
  
  // 第2引数 : このツールが何をするものかをAIに伝えるための説明
  "Get weather alerts for a state",
  
  // 第3引数 : ツールが受け取る「引数のスキーマ定義」(バリデーション)
  {
    state: z.string().length(2).describe("Two-letter state code (e.g. CA, NY)"),
  },
  
  // 第4引数 : 実際にツールが呼び出されたときに実行されるロジック
  async ({ state }) => {
    const stateCode = state.toUpperCase();
    const alertsUrl = `${NWS_API_BASE}/alerts?area=${stateCode}`;
    const alertsData = await makeNWSRequest<AlertsResponse>(alertsUrl);

    if (!alertsData) {
      return {
        content: [
          {
            type: "text",
            text: "Failed to retrieve alerts data",
          },
        ],
      };
    }

    const features = alertsData.features || [];
    if (features.length === 0) {
      return {
        content: [
          {
            type: "text",
            text: `No active alerts for ${stateCode}`,
          },
        ],
      };
    }

    const formattedAlerts = features.map(formatAlert);
    const alertsText = `Active alerts for ${stateCode}:\n\n${formattedAlerts.join("\n")}`;

    return {
      content: [
        {
          type: "text",
          text: alertsText,
        },
      ],
    };
  },
);

各サービスが提供しているMCP

MCPは自分でも作成できますが、よく使うサービスが提供してくれているMCPもあります。
使用しているサービスがMCPを提供している場合はそちらを使った方が賢明でしょう。

  • Figma MCP：LPデザイン案をAIが生成し、コンポーネント単位で調整
  • GitHub MCP：リポジトリ内のコード修正やプルリク作成を自動実行
  • Playwright MCP：E2EテストをAIが設計・生成・実行

chrome-devtools-mcpでの事例

chrome-devtools-mcpとは、Google公式のDevToolsプロトコルを利用した MCP（Model Context Protocol）サーバーで提供するブラウザ自動化ツールです。以下のような特徴があります。

  • GeminiがChromeを直接操作してテストや分析ができる（特にパフォーマンス測定の詳細分析が得意）
  • コンテキスト使用量（トークン使用量）は 類似ツールの Playwright MCP とほぼ同等
  • chrome-devtools-mcpはChrome専用なので他ブラウザテストには Playwright MCP がベター

以下の手順で試せるので気になった方は試してみてください。

  1. Gemini CLIをインストール
  • インストール方法の参考ページ

  1. chrome-devtools-mcpの設定
    対象プロジェクトのルートに.geminiというファイルを用意し、その中にsettings.jsonを作成
  • .gemini/settings.json
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["chrome-devtools-mcp@latest"]
    }
  }
}
  1. 対象プロジェクトを起点にターミナルでgeminiコマンド実施
    以下コマンドでchrome-devtools-mcpを備えたGemini CLIを立ち上げられる。
gemini

あとはプロンプトで指示し、Geminiの返答に応じるだけで進んでいく。

  • 雑なプロンプト例：yahooのサイトに行ってコメント数が上位の記事の内容を開き、その要約をして

実際、先の雑なプロンプトで意図通り動いてくれました。

随時承認を求められるのが少しだけ煩わしいですが、勝手にブラウザが立ち上がって、ページ遷移し、期待する結果を待っているだけで得られるのは大きなメリットですよね。

MCPはAIのブースタ機能という点で便利ですが、便利ゆえに注意しなきゃならない部分も少なくありません。

  • 運用上の留意点
    • APIキーや認証情報は.envなどで安全に管理する
    • 不要なリソース権限は付与しない
    • MCPサーバーを監視・停止できる仕組みを用意したほうがいい
    • 信用できる制作元のMCPを利用する（無作為にサードパーティMCPを使用しない）

MCPクライアントとMCPサーバーの通信方式

  • Stdio（標準入出力）

    • 安全かつ高速。ローカルでの開発や、ネットワークを使いたくないセキュリティ重視のケース向け
    • ネットワークを介さずプログラム同士が直接テキストデータをやり取りする

  • Streamable HTTPトランスポート

    • 大きなデータやリアルタイム性が必要なケース向け
    • 後述のHTTP+SSE方式よりもシンプルで柔軟
    • サーバーが単一のHTTPエンドポイント（例：/mcp）を提供。リクエストボディもレスポンスボディも両方ストリーミング可能
    • これにより、サーバーからの通知（notifications）やプログレス更新もリアルタイムで受け取れます
    • クライアントはHTTP POSTでリクエストを送信し、（サーバー）レスポンスはストリーミング（分割送信）で返される

  • HTTP+SSE

    • 現在はStreamable HTTPトランスポートを利用推奨
    • リアルタイムなデータ配信や、ChatGPTのように文字が徐々に表示されるようなケース向け
    • クライアントがHTTPリクエストでサーバーにアクセスし、サーバーからはSSEで複数のメッセージをストリーミング（サーバーからクライアントへの一方向通信）

A2A（Agent to Agent）とAI同士の連携

A2AはAI同士の通信規格で、MCPが「AIと外部サービス」の橋渡しを担うのに対し、A2Aは「AIとAIの協調」を実現します。
これにより、複数のAIエージェントが役割分担しながら協働可能になります。

仕様駆動開発（SDD）

AIは課題解決を最優先に、自律的に複数ファイルを高速修正するため、人間が全体を追い切れないこともあります。

Vibe Codingのような人間側で把握しきれない開発手法では、開発の堅牢性や保守・運用など将来性にも大きな影響を与える事態にもなりかねません。

そこで現在この問題を解消するためにAWSのkiroやGitHubのspec-kitに代表される 仕様駆動開発（SDD） が注目されています。

スペック / 仕様駆動開発（SDD）

「vibe codingなんて危なっかしくて実務では厳しいよね？」ということでAWSが「まずは仕様を決めて、設計や構成を割り振り、作業フェーズやタスク抽出してから」と段階を踏んでAIに作業してもらおうと提唱して生まれたスタイル（※正確にはこれを実施するAI搭載のIDE：kiro）になります。

具体的には以下です。

  1. したいことをAIに相談し、AIと壁打ちしながら仕様を決めていく。または人間が事前に整然としたドキュメントを用意しておく
  2. 決めた仕様をAI（と人間）が分かりやすいようにAIにまとめてもらって仕様書（requirements.md）を用意
  3. その仕様書をもとにAIが設計方針や構成、開発フェーズなどプロット（design.md）を策定
  4. そのプロットに問題なければ、具体的な実装アプローチやタスク割り出し、実行計画（task.md）を準備し、それに則って実施（開発）する
  5. 人間はAIが実施したタスクを都度レビューして修正・承認を行い開発を進めていく

AWSのkiroの後発となりますが、GitHubでもspec-kitという仕様駆動開発のオープンソースツールが公開されています。spec-kit では、以下のようなワークフローが紹介されています。

  • Establish project principles:
    /speckit.constitutionコマンドを使用して、その後のすべての開発のガイドとなるプロジェクトの管理原則と開発ガイドラインを作成します。
  • Create the spec:
    /speckit.specifyコマンドを使って、何を構築したいのかを説明しましょう。技術スタックではなく、何を、なぜ構築したいのかに焦点を当てましょう。
  • Create a technical implementation plan:
    /speckit.planコマンドを使用して、技術スタックとアーキテクチャの選択肢を指定します。
  • Break down into tasks:
    /speckit.tasksコマンドで実装計画から実行可能なタスクリストを作成するために使用します。
  • Execute implementation:
    /speckit.implementですべてのタスクを実行し、計画に従って機能を構築するために使用します。

このように、AIは実行・生成を担い、人間は上流設計・監督を担う体制へと移行しています。

  • SSDの中にVibe Coding的な工程要素がある （水の流れをうまくコントロールするイメージ）

Vibe Coding と SSD はよく相対的な関係性で説明されることがあるものの「SSDの中にVibe Coding的な工程要素がある」というのが筆者の所感です。

例えば、何も置いていないテーブルに水を垂らした状態をイメージしてみてください。水は自由自在に広がり、人間がコントロールすることは不可能となります。

しかし、テーブルに決まった溝を掘っていたり、パイプのような囲いを置いていたりすれば、水はある程度そのルートに沿って流れていきます。

人間側がルートを設けて水を流す（仕様を伝えてAIが自律的にコーディングする）と、水は期待通り流れていきますし、もしどこかで詰まったり、溢れ出てたりしても人間側でコントロールしやすくなります。

安全・堅実なVibe Codingの実現には、SSDが現状ベターな手法というイメージです。

AIとの協業において重要だと感じたポイントまとめ

  • 事前にある程度、環境を用意（構築）しておいた方が効率的
  • 上流設計が重要
    • AI は指示の内容が誤っていた場合もそれに合わせたコーディングを行ってしまう（人間側の求める答え・期待に過度に寄り添う姿勢を見せることがある）
    • AI は初期の頃に前提が間違っていた場合、後から修正するのが苦手
  • 長期間のセッションでは出力内容が段々と劣化していくため以下方法で対応していく
    • 一旦それまでの内容をAI自身に整理してもらった上で、会話履歴をリセットしてから進める
    • Claudeの場合： /clearコマンドを実行して「コンテキストウィンドウ（会話履歴）を破棄し、不要になった会話内容やファイル情報をリセット」する。作業が一区切りしたタイミングで/clearを使い、新しい会話として再スタートするのが効果的
    • 適宜別のセッションに分ける
      • ※タスク実行に必要な情報維持の観点から、作業別やフェーズごとなどタスクが一区切りしたタイミングでの実施を推奨
  • 0 -> 1 は得意だが、既存のものをベースにした修正などは苦手（都度スクラップアンドビルドして生成するため）
  • プロンプトは否定形ではなく肯定形で依頼する
  • 適切な専門用語を用いてAIと明確なコミュニケーションを図る
  • 機能要件（ユーザー管理機能やデータ処理、外部連携の有無など）を細かく伝えることで、AIがより正確な設計を提案してくれる。作業依頼（タスク）とは異なり、設計部分は詳しければ詳しいほど良い
  • 細粒度のタスクを具体的な指示で依頼する
  • 全自動化より「協働（役割分担）」前提で考える
  • Vibe Coding や AI を用いたコーディング・プログラミングには前提知識が求められる
    • 例えば、スタイルの修正依頼ひとつ取ってもドロップシャドウやブラー、ホバーなどの用語を知っていないと適切かつ端的な修正指示ができない
    • 作業依頼に関する補足情報または実装イメージがしっかりしないとうまく指示を出せない
      例えば、CRUD機能やデータベースの種類、データベースを用いない簡易なデータ管理方法（localStorage）など要件定義や技術選定に関わってくるような「何がしたいのか」を具体的に伝達できる知識が必要
  • 副次的に論理的思考力を磨くトレーニングにもなる
  • Vibe Coding は知らない記述・記法や未知のライブラリの勉強になるし、その場で聞けるのでキャッチアップ効率も高まる
  • ※Geminiの場合： Temperatureで成果物の創造性を調整
    • 創造性を高めたい場合はTemperatureを高め、正確性を重視する場合は下げるなど、生成特性を使い分ける

既存プロジェクトのリファクタリングや修正といったケース

例えば、既にいない第三者が開発したものだったり、ドキュメント不足のプロジェクトだったり、慣れない言語やフレームワークを使ったプロジェクトだったりする場合には以下を意識してみてください。

  • 情報・状況把握して、それらをAIに投げて壁打ちしながら仮説出し及びコード改修を進める
    • AIと協業することで言語やフレームワークをはじめ、プロジェクトの構造理解も捗るので作業効率が良い
  • タスク選定からフェーズ構築をはじめ、壁打ち時はAskモードで進めてAIの自律行動を抑制し、実際の作業開始時にAgentモードに切り替える
  • AI自身に対応箇所（タスク）を選定してもらい、作業フェーズも構築してもらう
    • フェーズを分けていないと壁打ちを続ける内に情報が埋もれたり、どうしても散らかったりしてしまうが、分けておくことで互いに情報整理と把握がしやすくなる
    • タスク実行前のフェーズで壁打ちして、コード理解やプロジェクト構造理解をしっかり深められないと次のタスク実施の判断もしづらくなる
  • プロンプトで作業に対する「（汎用的な）制約」を設ける
- まずはプロジェクトの全体像を把握して、どんなサイト・サービスかを言語化して
- ステップバイステップで作業フェーズを考えて、フェーズごとのタスクを想定および選定して
- フェーズが変わるタイミングやタスク実施時は随時確認して
- 不明点や疑問点があれば作業を止めて聞いて

まとめ

冒頭で述べたように、これは筆者が業務や個人開発などを通じて得た所感・情報をまとめたドキュメントです。
包括的な内容ではないものの、要所要所で活用できる部分もあるのではと記事にしました。

今後も当記事にキャッチアップ内容を適宜更新していきます。
ここまで読んでいただき、ありがとうございました。

参考記事

1
1
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
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?