LEEの自宅サーバ運用記 | 【2026年最新】Geminiの「スキル」をプロンプト集で終わらせない──機能要件と非機能要件で設計する「AIスキルのアーキテクチャ設計論」

📋 1分でわかるこの記事のまとめ

Gemとスキルの決定的な違い:
- Gemは「1チャット＝1人格（専門家の個室）」を人間が切り替える仕組み。
- スキルは「1エージェント＝複数ケイパビリティ（道具箱のツール群）」をAIが自律的に持ち替えて複合タスクを実行する仕組み。
プロンプト長文化（レシピ思考）の限界:
- 指示文の貼り付けだけでは「誤発火」「フォーマット崩れ」「ハルシネーション」「コンテキスト浪費」が多発し、チーム運用で破綻します。
スキル設計の「機能要件」4大要素:
- ① 起動トリガー（発火境界）
- ② 入力インターフェース（必須パラメータと不足時のガード）
- ③ 処理ワークフロー（決定論的ステップ分解）
- ④ 出力インターフェース（成果物スキーマ）
プロと素人を分ける「非機能要件」5大要素:
- セキュリティ境界、フォールバック、決定論（計算・コード）と非決定論（推論・要約）の分離、トークン効率、テスタビリティ（Evals）。
現場ですぐ使えるテンプレート同梱:
- 社内展開やチーム共有で属人化を防ぐ「AIスキル設計仕様書（Markdown）」を全文掲載。

はじめに：Geminiに「スキル」が実装された日

こんにちは、LEEです。

普段はインフラエンジニアおよびプレイングマネージャーとして活動しながら、PMP®（プロジェクトマネジメント・プロフェッショナル）および情報処理安全確保支援士（登録セキスペ）の知見を活かし、自律型AI組織の運営や開発効率化の技術検証を発信しています。

2026年、GoogleのGeminiに待望の新機能「スキル（Skills）」が実装されました。

これまでGeminiを活用してきたチームであれば、カスタム指示（Custom Instructions）を設定したり、特定の役割や社内データを持たせた「Gems」を作成して運用してきたはずです。

しかし、今回実装された「スキル」は、単なるGemsの名称変更やマイナーアップデートではありません。AIの活用パラダイムが、「1チャット1人格のチャットボット」から「複数のケイパビリティ（道具・能力）を動的にオーケストレーションする自律エージェント」へと移行した決定的な転換点です。

ところが、社内やコミュニティでの使われ方を見ていると、多くの人が以前のGemと同じように「これまでのプロンプトやお願い文を、そのままスキルの指示欄に貼り付ける」という使い方をしています。

これではスキルの真価を発揮できないどころか、意図しないタイミングでの誤発火や、フォーマット崩れ、ハルシネーションに悩まされることになります。

スキルとは「お願い文（プロンプト）」ではありません。**確率的に動作するLLMを制御し、再現性と安全性を担保するための「ソフトウェアコンポーネント」**です。

本記事では、インフラやアプリ開発における「機能要件・非機能要件」の設計思想をAIスキルに適用し、チームで安定運用できる堅牢なスキルアーキテクチャの作り方を徹底解説します。

第1章：Gemとスキルの根本的な違い──「人格の固定」から「ケイパビリティの疎結合」へ

まず押さえるべきは、Gemsとスキルの構造的な違いです。

【従来のGems（1対1・密結合モデル）】
[ユーザー] ──会話──> [専用Gem（人格＋指示＋固定データ）]
※ タスクごとに「Gem A」「Gem B」のチャットルームを人間が手動で切り替える

【これからのスキル（1対N・疎結合モデル）】
                      ┌──> [スキル A（議事録整形）]
[ユーザー] ──会話──> [メインGemini] ──┼──> [スキル B（ログ解析）]
                      └──> [スキル C（Sheets集計）]
※ 1つの会話の中で、文脈に応じてAIが自律的にスキルを呼び出し・組み合わせて実行する

1.1 「部屋の切り替え」から「道具の持ち替え」へ

従来の Gems は、いわば「専門家が待機している個室」でした。

「コードレビュー用Gem」
「社内規定FAQ用Gem」
「日報作成Gem」

ユーザーはタスクごとに部屋を移動して会話していました。この構造の最大の弱点は、「コードレビューをしてもらいながら、そのまま社内セキュリティ規定に適合しているかチェックさせ、最後にチケット起票用のフォーマットに整形する」といった一連の複合ワークフローを1つの画面で完結できない点にありました。

一方、新しく実装された スキル は「道具箱の中のツール群」です。ユーザーが対話する相手はメインのGemini（またはプロジェクトエージェント）であり、AIが必要に応じて道具箱から「コードレビュースキル」を取り出し、次に「社内規定チェックスキル」を取り出して順番に実行します。

つまり、**「人格の固定化」から「ケイパビリティ（能力）のプラグイン化・疎結合化」**へと進化したのです。

1.2 既存Gemからスキルへの移行ステップ

過去に作成したGem資産は、以下の3ステップでスキルへ解体・移行できます。

「人格・トーン」と「処理手順」を分離する: 「あなたは親切なPMです」といった人格部分はメインの基本指示に残し、「議事録からAction Itemを抽出する手順」だけを独立したスキルとして切り出します。
単一責任の原則（Single Responsibility Principle）を適用する: 1つのGemにあれもこれも詰め込んでいた場合、機能単位（例:「ログ抽出」「フォーマット変換」「チケット起票」）に小さなスキルとして分割します。
発火条件（Trigger）を明示する: Gemは人間が明示的に選んでチャットを開いていましたが、スキルはAIが文脈から自律的に呼び出します。「どういう文脈のときにこのスキルを発火させるか」の境界線を必ず定義します。

第2章：スキルの設定方法と社内連携の実務

スキルを現場で実用化するための、設定手順と外部データ・システム連携の実務です。

2.1 スキルの基本設定項目

Gemini（Google Workspace / Gemini Enterprise等）の管理・設定画面において、スキルは概ね以下の要素で構成されます。

スキル名 & ID: システムやAIが識別しやすい一意の命名（例: git-pr-reviewer, customer-inquiry-classifier）。英数字ハイフン繋ぎの識別子を設定しておくと、将来的なAPI連携時にも迷いません。
Description（概要・発火条件）: ここが最重要項目です。 AIのオーケストレーターが「このスキルを使うべきか否か」を判断するメタ情報となります。「何をするスキルか」「いつ呼び出すべきか」を簡潔かつ厳密に記述します。
Instructions（処理プロンプト・制約）: スキルの本体です。第3章で解説する機能要件・非機能要件を満たした構造化テキスト（Markdown）を流し込みます。
Resources & Tools（連携リソース）: 社内Google Drive、スプレッドシート、外部APIなどのアクセス権限を紐付けます。

2.2 社内データ・外部ツールとの連携設計

スキル単体ではテキストの整形しかできません。社内システムと繋ぎ込むことで初めて実務の武器になります。

Google Drive / ドキュメント連携のスコープ制限: フォルダ単位でスコープを絞って連携します。「会社全体のDrive」を無制限に読ませると、検索ノイズ（古い議事録や無関係なファイル）を拾ってハルシネーションを起こします。「特定の運用マニュアルフォルダのみ」に絞り込むのが鉄則です。
Google Sheets / Apps Script連携: 集計や計算をプロンプト内で直接やらせず、スプレッドシートの関数やスクリプトを実行させる連携を組みます。
外部API / MCP（Model Context Protocol）連携: GitHub、Slack、Jira、自社DBなどと連携する場合、ツールのI/Oスキーマ（引数と戻り値）を厳密に定義し、不要な書き込み権限（Write権限）を与えない最小特権の原則を徹底します。

2.3 チーム共有と権限管理の勘所

社内展開時によくある失敗が「誰でも編集可能にしてしまい、ある日突然プロンプトが壊れる」という事故です。

検証環境と本番環境の分離: スキルのバージョン管理（v1.0.0, v1.1.0）を行い、修正時はまず開発用のチャットで検証してから共有リポジトリへ反映します。
最小権限での共有: 利用メンバーには「実行権限（View / Use）」のみを付与し、「編集権限（Edit）」はスキルオーナー（PMやテックリード）に限定します。

第3章：エンジニア・PM視点で定義する「スキルの設計論」──レシピ思考からコンポーネント設計へ

ここからが本題です。スキルを単なる「プロンプト集」で終わらせず、堅牢な業務モジュールとして成立させるための設計論を展開します。

3.1 レシピ思考の限界──なぜ「プロンプトの長文化」は破綻するのか？

「あなたは優秀なマネージャーです」「丁寧に箇条書きでまとめてください」といった指示の羅列は、家庭料理の「レシピ」に過ぎません。これを業務システムとして運用しようとすると、以下の壁に直面します。

予期せぬタイミングで誤発火する（または必要なときに呼ばれない）
外部ツールから想定外のデータが返ってきたときにハルシネーションを起こす
出力形式が微妙に崩れ、後続の別スキルや人間の作業に繋がらない
指示文が長くなりすぎてコンテキストを浪費し、全体の推論精度が落ちる

システム開発において要件定義のないコードが破綻するのと同様に、スキルにも**「機能要件」と「非機能要件」**の定義が不可欠です。

3.2 スキルの「機能要件」を定義する（What：何を果たす部品なのか）

機能要件とは、「何を入力として受け取り、どのような手順で処理し、何を出力するか」という責務の明確化です。

【スキルの機能要件 4大要素】
1. 起動トリガー（発火条件・意図境界）
2. 入力インターフェース（引数・前提条件）
3. 処理ワークフロー（決定論的ステップ）
4. 出力インターフェース（成果物スキーマ）

① 起動トリガー（発火境界）

Geminiは会話の文脈から自律的にスキルを選びます。トリガーが曖昧だと無関係な会話に割り込みます。

❌ 悪い例:「業務の相談に乗る」
⭕ 機能要件としての定義:「ユーザーが『障害報告』『インシデント』という単語を含み、かつエラーログまたは監視アラートを提示したときにのみ発火する」

② 入力インターフェース（前提データ）

スキルが正しく動くために必要な前提条件を定義します。情報が不足している場合、LLMに勝手に推測（ハルシネーション）させるのではなく、**「追加入力を求めて即座に停止する」**というガードを組み込みます。

必須パラメータ: ログテキスト、発生時刻、対象サービス名
不足時の振る舞い: 必須項目が欠落している場合、「発生時刻と対象サービス名を入力してください」と問い返す

③ 処理ワークフロー（実行ステップ）

目的達成までの手順を、単一の大きな指示ではなく「ステップ・バイ・ステップ」に分解します。LLMは一度に複数の認知タスクを課されると精度が落ちます。「取得」「分析」「整形」を明示的なステップとして分離します。

Step 1: 与えられたログからエラーコードとスタックトレースを抽出する
Step 2: 連携された社内Driveの「過去インシデントナレッジ」から類似エラーを検索する
Step 3: 類似事例がある場合はその対処法を、ない場合は一般的な原因仮説を3点導出する
Step 4: 指定のMarkdownフォーマットに流し込む

④ 出力インターフェース（成果物スキーマ）

「わかりやすくまとめて」という曖昧な指定を排除し、見出し構造や必須項目を構文レベルで定義します。

必須セクション（概要、影響範囲、暫定対処、恒久対策）
箇条書きの階層制限
事実（Fact）と推測・仮説（Hypothesis）のセクション完全分離

3.3 スキルの「非機能要件」を定義する（How：品質・安全・堅牢性をどう担保するか）

エンジニアやPMの腕の見せ所は、この「非機能要件」にあります。非決定論的（出力に揺らぎがある）なLLMを、実務レベルの品質基準に収めるための制約設計です。スマートフォンでも読みやすいよう、カード形式で要点を整理します。

1. セキュリティ・境界（Security & Boundaries）

従来のシステム: 権限認可、ネットワーク隔離、データマスキング
スキル設計の解:
- 特定のDriveフォルダ以外へのアクセスを厳禁とする。
- 入力ログやドキュメントに含まれる個人情報（メールアドレス、氏名、IPアドレス）は出力時に自動で [MASKED] へ置換するルールを敷く。

2. 信頼性・堅牢性（Reliability & Fault-Tolerance）

従来のシステム: 例外処理、リトライハンドリング
スキル設計の解:
- 外部ツールの呼び出しエラー時のフォールバックを定義する（例: 検索失敗時は一般推論に切り替え、その旨を明記）。
- 推論の確信度が低い場合、無理に回答を作らせず「人間へのエスカレーション」を促す基準を明示する。

3. 決定論と非決定論の分離（Deterministic vs Probabilistic）

従来のシステム: ロジックの正確性と計算再現性
スキル設計の解:
- 「計算・集計・フォーマット検証」はコードやスプレッドシート（決定論）に任せる。
- 「要約・文脈理解・定性分析」のみをLLM（非決定論）に任せる。
- プロンプトの中でLLMに足し算やパーセンテージ計算をさせてはいけません。

4. コンテキスト効率（Maintainability & Token Budget）

従来のシステム: メモリ最適化、遅延読み込み（Lazy Loading）
スキル設計の解:
- スキルの指示文自体は最小限の軽量メタデータに保つ。
- 膨大なマニュアルや過去の事例集はプロンプトに常駐させず、必要な瞬間だけ外部Driveから動的に引き出す「Progressive Disclosure（段階的情報開示）」を採用する。

5. テスタビリティ（Testability & Evals）

従来のシステム: 単体テスト、結合テスト、CI/CD回帰テスト
スキル設計の解:
- 代表的な入力パターン（正常系・異常系・境界値）を5〜10件用意し、プロンプトを修正するたびに期待する出力形式が維持されているかを検証するEvalsテストセットを整備する。

第4章：実践！現場でそのまま使える「AIスキル設計仕様書」テンプレート

チームでスキルを量産・共有する際は、属人化を防ぐために以下の仕様書フォーマットで定義することを推奨します。そのままコピーして活用してください。

# [スキル名] 仕様書

## 1. メタデータ
- **スキルID**: `ops-incident-analyzer`
- **バージョン**: `1.0.0`
- **オーナー**: SREチーム（担当: 山田）
- **最終更新日**: 2026-11-02

## 2. 機能要件 (Functional Requirements)
### 2.1 目的と責務
サーバー障害・エラー発生時に、ログと社内ナレッジを突合し、初動対応用のインシデント報告ドラフトを5分以内に作成する。

### 2.2 起動トリガー（発火境界）
- **発火条件**: ユーザーがエラーログ、スタックトレース、またはアラート通知を貼り付け、「障害」「エラー」「動かない」と言及したとき。
- **除外条件**: 通常のコード実装相談や、インフラの新規構築相談では発火させない。

### 2.3 入力前提条件
- **必須**: エラーログ本文（最低限スタックトレースまたはHTTPステータスコードを含むこと）
- **任意**: 発生時刻、影響を受けているサービス名（未入力の場合は推測せず、出力時に「【未確認】」と明記）

### 2.4 外部ツール・参照リソース
- Google Drive: `Knowledge/SRE/Past-Incidents/` フォルダ配下のMarkdownのみ参照
- Google Docs: インシデント報告テンプレート（ID: `doc-template-xxxx`）

### 2.5 実行ワークフロー
1. 入力ログから「エラー種別」「起因モジュール」を特定
2. 社内ナレッジを検索し、過去3ヶ月以内の類似事例を最大2件抽出
3. 影響範囲の仮説と、推奨される初動コマンド（再起動、ロールバック等）を特定
4. 後述のフォーマットでMarkdown出力

### 2.6 出力フォーマット
# 【初動報告】インシデント概要
- **発生事象**: [事実のみを1行で記載]
- **影響範囲**: [確認された影響、または【要確認】]
- **推定原因（仮説）**: [理由とともに箇条書きで記載]
- **推奨初動アクション**:
  1. [コマンドまたは操作手順]
- **類似の過去インシデント**: [URLまたはファイル名 / なければ「なし」]

---

## 3. 非機能要件 (Non-Functional Requirements)
### 3.1 セキュリティ・コンプライアンス
- ログ内に含まれる個人情報（メールアドレス、IPアドレス、氏名）は出力時に `[MASKED]` へ置換する。
- 参照権限外の社内ドキュメントへのアクセスを試行しない。

### 3.2 堅牢性・ハルシネーション制御
- 原因が不明な場合、「〜が原因です」と断定せず、「現在のログからは特定不能（仮説: 〜）」と明記する。
- 過去事例に該当がない場合、架空のインシデント履歴を捏造しない。

### 3.3 フォールバック
- Google Driveの検索がタイムアウト、または該当ゼロの場合は、外部参照をスキップしてログの一般的な解析結果のみを返し、その旨を注記する。

### 3.4 テストケース（Evals）
- **Test 1（正常系）**: NullPointerExceptionのログを入力 → 過去事例と対処法がフォーマット通り出力されること。
- **Test 2（異常系・情報不足）**: 「サーバーが落ちました」の1行のみ入力 → ログの提示を促すエラー応答が返ること。
- **Test 3（セキュリティ）**: ユーザーのメールアドレスが含まれるログを入力 → 出力結果でマスクされていること。

おわりに：プロンプトエンジニアから「AIアーキテクト」へ

プロンプトエンジニアリングの黎明期は、「AIにいかに気の利いたお願いをするか」という呪文探しの時代でした。

しかし、Geminiにスキルが実装され、エージェントが複数のツールや社内データを自律的に使い分けるようになった今、求められているスキルセットは完全に変わりました。

それは、**「確率的に揺らぐAIモデルを、信頼できるビジネスコンポーネントとして要件定義し、アーキテクチャに落とし込む力」**です。

機能要件で、トリガーとI/Oの責務境界を明確にする。
非機能要件で、セキュリティ、決定論の境界、フォールバック、評価基準を固める。

この思想を持ってスキルを設計すれば、社内のGeminiは「たまに気の利いた答えを返すチャットボット」を脱し、チームの屋台骨を支える堅牢な自律モジュールへと進化します。

ぜひ、今回紹介した仕様書テンプレートを使って、あなたのチームの業務を1つ「スキル化」してみてください。

【2026年最新】Geminiの「スキル」をプロンプト集で終わらせない──機能要件と非機能要件で設計する「AIスキルのアーキテクチャ設計論」