Geminiで毎回「この形式でまとめて」「不明な点は推測しないで」と説明しているなら、その指示を再利用するためのskillsが新しい選択肢になります。Googleは、個人向けGemini AppsのGemsを2026年11月からskillsへ移行する予定を案内しています。
2026年10月14日時点の公式ヘルプでは、skillsは通常のチャットから呼び出せる、再利用可能なカスタム指示として説明されています。複数の指示を組み合わせたり、関連する作業に自動で適用したりできる点が特徴です。ただし、Gemsの機能がすべてそのまま使えるわけではありません。特にCanvasやDeep Researchを使う人は、移行前に対応範囲の確認が必要です。
SEやフリーランスにとっての価値は、AIへ渡す作業ルールを、毎回書き直す文章から管理できる業務資産へ変えられることです。本記事では公式情報と、そこから考えられる実務上の使い方を分けて整理します。以下の業務例は導入案であり、実機での検証結果ではありません。
Geminiのskillsは、仕事の進め方を保存して使う仕組み
skillsは、特定の作業をどう進めるかをGeminiへ教えるための指示です。たとえば「障害メモを整理するときは、確認済みの事実・仮説・次の確認事項を分ける」というルールを保存しておけば、別の会話でも同じ方針を使えます。単に過去の回答を保存するのではなく、次の入力に対して適用する手順を残す考え方です。
公式ヘルプによると、有効なskillは文脈に応じて自動適用されるほか、利用者が明示的に指定することもできます。呼び出しには「/」を使い、更新された環境では「@」を使う案内があります。自分の画面に出る候補から選ぶのが確実です。作成・管理に関する公式ヘルプ
実務で考えたいのは、「何でもやる万能アシスタント」を一つ作るより、目的が分かる小さな作業ルールに分けることです。「議事録の整理」「SQLの確認観点」「顧客への進捗報告」といった単位なら、どの場面で使うかを判断しやすくなります。
逆に「常に最高の回答をする」「すべての問題を解決する」といった指示は、成果物の良し悪しを評価しにくくなります。入力に何が含まれ、何を出力し、どこで判断を止めるかまで書くと、利用者とAIの認識をそろえやすくなります。
Gemsからの移行予定と、先に確認したい機能の違い
Googleの移行ヘルプでは、個人のGoogleアカウントは2026年11月、Workspaceの企業・非営利団体向けアカウントは2027年3月、教育向けアカウントは2027年6月にGemsのサポートを終了する予定です。Gemsと対応するファイルは自動的にskillsへ移行する方針も示されています。これらは2026年10月14日時点の予定であり、今すぐ全員のGemsが消えるという意味ではありません。Gemsからskillsへの移行に関する公式ヘルプ
同じ公式ヘルプでは、skillsは現時点でCanvasやDeep Researchに対応していないと説明されています。Gemsでこれらを使っていた場合、名前や指示が移行されても、同じ作業が同じように動くとは限りません。自動移行を待つ場合でも、利用中の機能を先に一覧化しておくと、移行後に止まる仕事を減らせます。
まず整理したいのは、Gemsの名前、保存した指示、参照資料、普段の入力例、期待する出力、使用するツールです。指示だけを見ると移行できそうでも、実際は特定のツールに依存していることがあります。ツール依存の作業と、文章整理だけで完結する作業を分ければ、先に試せる範囲が見えてきます。
自動移行を理由に、確認前から元のGemsを削除する必要はありません。重要な指示は手元にも控え、公開してよいサンプル入力で新旧の結果を比較する方が現実的です。「存在すること」と「仕事に使えること」を別々に確認する、という移行作業の基本がここでも役立ちます。
無料で使える範囲と、個人・仕事用アカウントの注意点
公式の作成・管理ヘルプは、skillsをチャットで利用するためにGoogle AIの有料契約は必要ないと案内しています。一方、Tasksやスケジュールの利用条件は別です。skillsが使えることを理由に、すべての自動実行機能まで無料だと判断しないようにしましょう。
個人向けGemini Appsでskillsを作成・利用する条件として、18歳以上、個人のGoogleアカウントへのログイン、Keep Activityの有効化が示されています。段階的な提供のため、対象条件を満たしても画面にまだ表示されない可能性があります。仕事用・学校用アカウントについては、この個人向けヘルプとWorkspace側の案内を分けて確認する必要があります。
会社のアカウントで機能が見つからないとき、個人アカウントへ業務資料を移して試すのは適切な回避策とは限りません。使える機能を探す前に、案件で許可されているアカウントと入力可能なデータを確認してください。架空のログや公開済みの仕様書であれば、実データを持ち込まずに手順を検討できます。
また、有料契約の有無と、成果物の正しさは別問題です。skillsは指示の再利用を助ける機能なので、誤った前提や古いルールを保存すると、それも繰り返し適用される可能性があります。料金の比較だけでなく、誰が指示を更新し、どの入力で確認するかを決めることが運用コストに関わります。
SE実務で試しやすいのは、判断を助ける文書作業
障害メモを「事実・仮説・次の確認」に分ける
最初の導入案として扱いやすいのは、障害調査メモの整理です。時系列が入り乱れたメモを読みやすくし、確認済みの情報と原因候補を分ける作業なら、結果を人間が見比べやすいからです。
たとえば「接続エラーが出た」「再起動後は復旧した」「同時刻に設定変更があった」という入力があっても、設定変更が原因だとはまだ言えません。skillには、原因を断定せず、根拠がない場合は不足するログや時刻を確認事項へ回すよう指定します。読みやすさと引き換えに情報の確度を落とさないことが狙いです。
この段階では、実サーバーの操作や設定変更まで任せる必要はありません。調査の入口を整えるだけでも、担当者への引き継ぎや、別チームとの会話に使える余地があります。現場で評価するなら、元メモから事実が抜けていないか、AIが原因や復旧時刻を追加していないかを見ます。
レビュー前の確認観点をそろえる
コードやSQLのレビューでは、「権限チェック」「入力値」「例外処理」「更新対象の範囲」など、毎回同じ観点を指示することがあります。これをskillへ保存すれば、依頼時の説明を短くできます。
ただし、skillsを使ったというだけでコードの安全性が保証されるわけではありません。AIの指摘は候補として扱い、再現条件や該当箇所を確認します。「重大そうな指摘が多い」よりも、「根拠があり、担当者が次の確認を行える指摘か」で評価する方が業務には向いています。
レビュー用skillには、コードが不足している場合に推測で補わないこと、判断根拠と確認できない範囲を書くことを含めます。存在しない周辺処理を前提にした指摘が減れば、人間の確認にかかる手間を抑えられる可能性があります。
顧客への進捗報告を整える
フリーランスSEなら、作業メモから進捗報告の下書きを作る用途も考えられます。「完了したこと」「残っていること」「相手に確認したいこと」を分け、未確定の納期を確約しないルールを保存します。
報告文を自動送信するところまで広げず、まずは下書き作成に限定すると評価しやすくなります。技術的には正しい文章でも、契約範囲や相手との合意に合わない表現が混ざることがあります。最終的な約束や送信の判断は、案件の責任者が確認する運用にします。
最初のskillには、入力・手順・停止条件を書く
以下は、障害メモ整理用の指示案です。Geminiでの動作を検証済みのテンプレートではありません。自分の業務に合うよう調整する出発点として使ってください。
用途：障害調査メモを整理する。 入力：利用者が渡したメモ、ログ抜粋、確認済みの時刻。 手順： 1. 確認済みの事実を時系列に並べる。 2. 原因候補は「仮説」と明記し、根拠を添える。 3. 不足している情報を、次の確認事項として挙げる。 4. 事実・仮説・次の確認事項の順に出力する。 制約： 入力にない日時、原因、実行結果を作らない。 認証情報や個人情報があれば、そのまま再掲しない。 本番環境の操作や外部送信は行わない。 判断に必要な情報が足りない場合は、断定せず不足を示す。
ここで大切なのは、長い文章にすることではありません。「入力にない事実を作らない」「原因が未確定なら仮説と表示する」といった、成果物を評価できるルールを残すことです。読む人によって解釈が大きく変わる指示より、守れたかどうかを確認できる指示が向いています。
作成後は、情報が十分なメモ、時刻が欠けたメモ、複数の原因候補があるメモを試します。きれいな入力だけで確認すると、困った場面での動作を見落とします。skillの価値が出るのは、入力が不完全なときでも不足を正しく扱える場面です。
複数のskillsを組み合わせる前に、指示の衝突を減らす
複数のskillsを同じ会話で使える点は便利ですが、最初から多くを有効にすると、どの指示が結果へ影響したか分かりにくくなります。たとえば「短い報告文にする」と「根拠を詳しく示す」を同時に使うと、必要な根拠が省かれたり、想定より長い出力になったりする可能性があります。
実務では、一つのskillで期待どおりの出力が得られることを確認し、その後に文章表現など別の役割を追加する順序が扱いやすいでしょう。作業手順を決める指示と、表現を整える指示を分けておけば、問題が出たときに切り分けやすくなります。
自動適用も、必ず意図どおりに起きる前提で設計しない方がよいでしょう。重要な仕事では、使いたいskillを明示して、出力に必要な条件が反映されているかを確認します。指示を保存したことで、依頼内容や結果の確認が不要になるわけではありません。
チームで管理するなら、skillごとに担当者、対象業務、最終見直し日、確認用の入力を残します。「誰かが便利そうな指示を追加した」状態を続けるより、使われる場面と更新理由が追える状態にすると、古い手順を整理しやすくなります。
Workspaceのskillsと、個人向けGeminiのskillsを分けて考える
Googleは2026年9月16日のWorkspace公式ブログで、チームのルールや参照資料を再利用するskillsを紹介しています。Google Docsで共同編集し、Workspace Studioで作成・テスト・管理する仕組みが説明されています。また、利用には管理者によるGemini Beta設定の有効化が必要と案内されています。Workspaceのskillsに関する公式発表
個人向けアプリでskillsが使えることと、組織全体へ配布して共同運用できることは、別々に確認する必要があります。どちらも「skills」という名前だからといって、作成画面、共有方法、利用可能な機能まで同じとは限りません。
情報システム担当者が導入を検討するなら、まず「どのアカウントの、どの画面で使うのか」を決めます。個人検証の結果をそのまま組織展開の計画へ持ち込むと、管理設定や提供時期の違いで手戻りが起きます。共有する指示の中に顧客名、社内URL、秘密情報を直接書き込まない設計も必要です。
フリーランスの場合は、共通の作業手順と案件固有の情報を分けて持つと管理しやすくなります。「障害メモを整理する順序」は共通化できますが、顧客の連絡先や環境情報は案件ごとに扱います。別案件で同じskillを使う際に、前の案件の情報が混ざらないことを確認してください。
Gemsを使っている人が、今から進めたい確認
まず、普段使っているGemsを、指示中心のものと特定の機能に依存するものに分けてください。指示中心のGemsから小さく試し、CanvasやDeep Researchなどを使うGemsは、対応状況を確認してから扱う方が移行判断をしやすくなります。
次に、移行前の出力を正解の基準として盲目的に使うのではなく、その作業で守るべき条件を書き出します。障害報告なら、未確認の原因を断定しないこと。レビューなら、根拠のない指摘を確定扱いしないこと。進捗報告なら、未合意の納期を約束しないことです。この条件を新しいskillでも確認します。
評価するときは、AIが回答するまでの時間だけでなく、人間の手直し時間も記録します。文章がすぐに生成されても、誤った事実の削除や不足情報の追記に時間がかかれば、業務全体は短くなりません。skillなしの依頼と同じ入力で比較すると、説明の手間と修正の手間の両方を見られます。
skillsが向くのは、似た作業を繰り返し、毎回伝えるルールがある人です。一回限りの質問や、まだ手順が定まっていない仕事なら、通常のチャットで条件を整理してから保存する方が扱いやすいでしょう。まずは公開情報や架空のデータで一つ作り、期待する条件を満たすか確かめる。その小さな確認から始めるのが現実的です。
参考情報
- Google公式ヘルプ：Create & manage skills for Gemini Apps
- Google公式ヘルプ：About the transition from Gems to skills
- Google Workspace公式ブログ：Teach Gemini your team’s know-hows with skills in Google Workspace
情報確認日：2026年10月14日。提供状況、移行予定、対応機能は変更される可能性があります。実務例と指示案は、本記事で提案する運用方法です。
コメント