はじめに
株式会社エスプリフォートは、
「ITの力でお客様のビジネスを支え、笑顔と価値を創造する」
という理念を大切にしているシステム開発会社です。
私たちは、AIをただ流行りのツールとして眺めるのではなく、
お客様の課題解決、開発品質の向上、エンジニア自身の成長、そして仲間の幸せにつなげる技術として活用したいと考えています。
エスプリフォートのクレドには、
「顧客価値を意識し、価値創造を全力で行う」
という考え方があります。AI時代のエンジニアに求められるのは、単にコードを書く力だけではありません。
AIを使って、より早く、より深く、より本質的に価値を出す力です。
今回紹介するのは、Google Geminiの Gem です。
これは、システムエンジニアにとってかなり強力です。
なぜなら、GemはただのチャットAIではなく、
自分専用の“AIメンバー”を作れる機能だからです。
Gemとは何か？
Gemは、Google Geminiで使えるカスタムAIエキスパートです。Google公式では、キャリアコーチ、ブレスト相手、コーディング補助など、目的に合わせたカスタムAIとして説明されています。(Gemini)
簡単に言えば、毎回こういう長い指示を書かなくてよくなります。
あなたは経験豊富なシステムエンジニアです。
以下のソースコードをレビューしてください。
観点は、可読性、保守性、例外処理、命名、パフォーマンス、セキュリティです。
最後に修正案も出してください。
このような指示をGemにあらかじめ登録しておけば、次回からはそのGemを開いて、ソースや資料を渡すだけで、毎回同じ観点でレビューしてくれます。
つまりGemは、
よく使うプロンプトを“業務専用AI”として固定化する仕組み
です。
Google公式でも、Gemは繰り返し使うタスクのために詳細なプロンプト指示を保存できる機能として紹介されています。(Gemini)
なぜSEに刺さるのか？
SEの仕事は、毎回ゼロから考えることばかりではありません。
むしろ現場では、同じような確認作業が大量にあります。
- コードレビュー
- 設計書レビュー
- SQLレビュー
- テスト観点の洗い出し
- 障害原因の整理
- 議事録の要約
- 仕様変更の影響調査
- 既存ソースから仕様を読み解く
- 顧客向け説明文の作成
- 若手メンバーへの説明資料作成
これらは毎回内容こそ違いますが、
見るべき観点、出すべき形式、判断基準はかなり共通しています。
ここにGemが刺さります。
毎回プロンプトを考えるのではなく、
“この仕事はこのGemに任せる”
という状態を作れるからです。
たとえば、以下のようなGemを作れます。
コードレビューGem
設計書レビューGem
SQLチューニングGem
テスト観点洗い出しGem
障害分析Gem
仕様書作成Gem
若手教育Gem
顧客説明文作成Gem
これは、ただ便利というレベルではありません。
SEの仕事の標準化、品質向上、教育、属人化解消に直結します。
GeminiのGemで特に強いポイント
1. 毎回のプロンプト作成が不要になる
AI活用で意外と面倒なのが、毎回プロンプトを書くことです。
最初は楽しくても、実務で毎日使うとなると、
「また同じ指示を書くのか」
となります。
Gemを使えば、役割・目的・出力形式・注意点を固定できます。
たとえば、コードレビューGemなら、最初から以下を仕込んでおけます。
あなたは経験豊富なシステムエンジニアです。
レビュー対象のコードに対して、以下の観点で確認してください。
# 観点
- 可読性
- 保守性
- 命名
- 例外処理
- セキュリティ
- パフォーマンス
- テストしやすさ
- 将来の仕様変更への耐性
# 出力形式
1. 総評
2. 問題点
3. 改善案
4. 修正例
5. 初級エンジニア向けの解説
これを一度Gemにしておけば、毎回のレビューがかなり速くなります。
2. Persona / Task / Context / Formatで設計できる
Google公式ヘルプでは、良いGemの指示を作る観点として、
Persona、Task、Context、Format
が紹介されています。(Google ヘルプ)
SE向けに言い換えると、こうです。
Persona：誰として振る舞うか
Task：何をするか
Context：どんな前提・背景で判断するか
Format：どんな形式で出すか
これは、プロンプト設計というより、ほぼ設計書です。
エンジニアなら、この考え方はかなり馴染みやすいはずです。
例：設計書レビューGem
# Persona
あなたは、業務システム開発に強い上級SE兼テックリードです。
# Task
ユーザーが貼り付けた設計書をレビューし、抜け漏れ・曖昧な表現・実装時のリスク・テスト観点不足を指摘してください。
# Context
対象は業務系Webシステムです。
開発者、テスター、顧客担当者が同じ設計書を読む前提です。
曖昧な表現は後工程の手戻りにつながるため、具体化してください。
# Format
以下の形式で出力してください。
1. 総評
2. 致命的な問題
3. 曖昧な仕様
4. 実装時のリスク
5. テスト観点
6. 顧客に確認すべき質問
7. 修正版の文章例
これだけで、設計書レビューの質が一段上がります。
SEが今すぐ作るべきGem 7選
1. ソースコードレビューGem
これは最優先で作るべきです。
あなたは上級SE兼コードレビュアーです。
ユーザーが貼り付けたコードを、以下の観点でレビューしてください。
# レビュー観点
- 可読性
- 保守性
- 命名
- 責務分離
- 例外処理
- セキュリティ
- パフォーマンス
- テスト容易性
- 将来の仕様変更への強さ
# 出力形式
1. 良い点
2. 修正すべき点
3. 重大度
4. 修正理由
5. 修正例
6. 若手エンジニア向けの解説
ポイントは、単に「悪いところを指摘して」ではなく、
なぜ悪いのか、どう直すのか、若手にどう説明するのかまで出させることです。
これにより、レビューが教育にもなります。
2. 既存ソースから仕様書を起こすGem
現場でかなり使えます。
仕様書が古い。
仕様書がない。
担当者が退職している。
でもソースはある。
この状況、珍しくありません。
あなたはレガシーシステム解析に強い上級SEです。
ユーザーが貼り付けたソースコードを読み取り、仕様書として整理してください。
# やること
- 処理概要を説明する
- 入力値を整理する
- 出力値を整理する
- 分岐条件を表にする
- 外部連携があれば整理する
- DBアクセスがあればテーブル・カラム・条件を整理する
- 例外処理を整理する
- 不明点は推測せず「要確認」と書く
# 出力形式
1. 機能概要
2. 処理フロー
3. 入力
4. 出力
5. 条件分岐表
6. DBアクセス
7. 外部連携
8. 例外処理
9. 要確認事項
このGemは、保守開発・リプレイス・マイグレーションでかなり強力です。
特に、
「ソースを読める人しか分からない」状態を、チームで共有できる状態に変える
という意味で価値があります。
3. テスト観点洗い出しGem
テストケース作成は、AIとの相性がかなり良いです。
あなたは品質保証に強いテスト設計者です。
ユーザーが提示した仕様をもとに、テスト観点を洗い出してください。
# 観点
- 正常系
- 異常系
- 境界値
- 入力チェック
- 権限
- 排他制御
- データ不整合
- パフォーマンス
- セキュリティ
- 既存機能への影響
# 出力形式
| No | テスト観点 | 確認内容 | 重要度 | 補足 |
これを使えば、若手でもテスト観点の抜け漏れを減らせます。
もちろん最終判断は人間が行う必要があります。
しかし、最初のたたき台としては非常に強いです。
4. SQLレビューGem
SQLは、動けばOKになりがちです。
しかし実務では、パフォーマンス、インデックス、可読性、保守性が重要です。
あなたはDB設計とSQLチューニングに強いSEです。
ユーザーが貼り付けたSQLをレビューしてください。
# 観点
- 実行計画上の懸念
- インデックス利用
- JOIN条件
- WHERE句
- N+1の可能性
- 集計処理の負荷
- 可読性
- 保守性
- NULL考慮
- 想定データ量に対するリスク
# 出力形式
1. SQLの目的推定
2. 問題点
3. パフォーマンス懸念
4. 改善案
5. 修正版SQL例
6. 確認すべき実行計画
SQLレビューGemは、レビュー工数削減だけでなく、
若手がDBの考え方を学ぶ教材にもなります。
5. 障害分析Gem
障害対応で大切なのは、感情ではなく整理です。
あなたは障害対応に強いシステムエンジニアです。
ユーザーが提示した障害情報をもとに、原因分析と対応方針を整理してください。
# 入力される可能性がある情報
- エラーログ
- 発生時刻
- 再現手順
- 影響範囲
- 直前のリリース内容
- 環境情報
- ユーザー操作
# 出力形式
1. 現象
2. 影響範囲
3. 想定原因
4. 切り分け手順
5. 暫定対応
6. 恒久対応
7. 再発防止策
8. 顧客向け説明文
これは本当に現場で使えます。
特に、障害時は焦ります。
焦ると情報が散らばります。
散らばった情報を構造化するだけで、対応速度が上がります。
6. 顧客説明文作成Gem
SEは技術だけ分かっていればいい、という時代ではありません。
お客様に伝わる言葉で説明できることも重要です。
あなたは顧客折衝に強い上級SEです。
技術的な内容を、非エンジニアのお客様にも分かるように説明してください。
# 方針
- 専門用語を使いすぎない
- 不安を煽らない
- 事実と推測を分ける
- できること、できないことを明確にする
- 次のアクションが分かるようにする
# 出力形式
1. お客様向け説明文
2. 技術者向け補足
3. 確認事項
4. 注意すべき表現
これがあると、メール、議事録、障害報告、仕様確認がかなり楽になります。
7. 若手教育Gem
人に教えるのは、かなり難しい仕事です。
でも、教える内容を整理するGemがあれば、教育の質を上げられます。
あなたは若手エンジニア育成に強い先輩SEです。
ユーザーが指定した技術テーマについて、初学者にも分かるように説明してください。
# 方針
- いきなり専門用語で説明しない
- たとえ話を使う
- 実務でどう使うかを説明する
- よくあるミスを入れる
- 最後に確認問題を出す
# 出力形式
1. まず一言で説明
2. たとえ話
3. 実務での使いどころ
4. よくあるミス
5. サンプルコード
6. 確認問題
若手教育は属人化しやすい領域です。
Gemを使えば、教育コンテンツの品質をそろえやすくなります。
Gemを作るときのコツ
コツ1：役割を曖昧にしない
悪い例：
コードを見てください
良い例：
あなたはJava/Spring Bootの業務システム開発に強い上級SEです。
保守性、例外処理、責務分離、テスト容易性の観点でレビューしてください。
AIは、役割が明確なほど安定します。
コツ2：出力形式を固定する
Gemは、毎回同じ形式で出力させると強いです。
# 出力形式
1. 結論
2. 理由
3. 問題点
4. 改善案
5. 次に確認すべきこと
このように固定すると、レビュー結果をチームで比較しやすくなります。
コツ3：「推測」と「事実」を分けさせる
AI活用で一番怖いのは、もっともらしい間違いです。
そのため、Gemには必ずこう書いておくべきです。
不明な点は推測で断定せず、「要確認」と明記してください。
事実、推測、提案を分けて出力してください。
これだけで、実務利用の安全性がかなり上がります。
コツ4：レビュー観点をGemに埋め込む
SEの仕事では、観点が重要です。
「見てください」ではなく、
「何を見てほしいのか」
をGemに固定します。
たとえばコードレビューなら、
可読性
保守性
例外処理
セキュリティ
パフォーマンス
テスト容易性
設計書レビューなら、
曖昧な仕様
入力・出力
例外系
権限
排他制御
データ整合性
運用時の影響
このように観点を固定するだけで、Gemの精度は上がります。
コツ5：Gemを“現場の標準化ツール”として考える
Gemは個人の便利ツールで終わらせるともったいないです。
チームで使うなら、以下のように標準化できます。
コードレビューはこのGem
設計書レビューはこのGem
障害報告はこのGem
議事録はこのGem
顧客説明文はこのGem
これにより、アウトプットの品質がそろいます。
これは、チーム開発におけるかなり大きな価値です。
Workspaceと組み合わせるとさらに強い
Google Workspaceの環境では、GemはDocs、Slides、Sheets、Drive、Gmailのサイドパネルでも利用できるようになっています。Google Workspace Updatesでは、GemをWorkspaceアプリのサイドパネルに持ち込み、アプリを切り替えずに使えるようになったことが発表されています。(Workspace Updates Blog)
これはかなり実務向きです。
たとえば、
- Gmailで顧客返信文を作る
- Docsで設計書レビューをする
- Sheetsで課題一覧を整理する
- Drive上の資料を見ながら要約する
- Slidesで提案資料の構成を作る
こうした作業の中でGemを呼び出せます。
つまり、AIを別画面で使うのではなく、
普段の業務の中にAIを埋め込める
ということです。
Gem活用でSEの仕事はどう変わるか？
1. “作業者”から“設計者”に近づく
AIが下書きや観点出しを支援してくれると、SEはより上流の判断に時間を使えます。
たとえば、テスト観点をゼロから書く時間を減らし、
「この観点は本当に必要か？」
「顧客の業務リスクはどこか？」
「今回の仕様変更で一番危ない箇所はどこか？」
を考える時間が増えます。
これは、単なる効率化ではありません。
SEの仕事が、
作業中心から価値判断中心へ変わる
ということです。
2. 属人化を減らせる
ベテランSEの頭の中には、レビュー観点、障害対応の勘所、顧客説明の型があります。
でも、それが頭の中にあるだけではチームの資産になりません。
Gemに落とし込めば、
ベテランの観点をチームで共有できる
ようになります。
これはかなり大きいです。
若手は成長しやすくなります。
中堅はレビュー負担を減らせます。
リーダーは品質を見やすくなります。
3. 顧客価値を出すスピードが上がる
SEの仕事は、コードを書くことが目的ではありません。
お客様の業務を理解し、課題を解決し、価値を届けることが目的です。
Gemで以下の作業が速くなれば、
- 調査
- 整理
- レビュー
- 説明
- 提案
- 教育
- 改善
お客様に価値を届けるスピードも上がります。
AI活用の本質は、
ラクをすることではなく、価値創造の速度を上げること
です。
実務で使うときの注意点
Gemは強力ですが、万能ではありません。
特にSEが使う場合は、以下に注意すべきです。
- 機密情報を安易に入れない
- 顧客情報、個人情報、認証情報を入れない
- AIの回答をそのまま採用しない
- 実行前に必ず人間が確認する
- ソースコードや設計の最終責任は人間が持つ
- 推測と事実を分ける
AIは優秀な補助者です。
しかし、責任者ではありません。
AIを使いこなすSEは、
AIに任せるところと、人間が判断するところを切り分けられる人です。
まとめ
GeminiのGemは、単なる便利機能ではありません。
SEにとっては、
自分やチームの仕事の型をAI化する仕組み
です。
コードレビューの型。
設計書レビューの型。
障害分析の型。
顧客説明の型。
若手教育の型。
仕様書作成の型。
これらをGemにすれば、
毎回ゼロから考える必要がなくなります。
そして、エンジニアはもっと大事なことに時間を使えます。
何が本質的な課題なのか
どうすれば顧客価値につながるのか
どうすればチーム全体の成果が上がるのか
どうすればより良いシステムになるのか
AI時代に必要なのは、AIに使われることではありません。
AIを使って、より大きな価値を創ることです。
最後に
エスプリフォートは、ただ技術を扱う会社ではありません。
技術を通じて、お客様、仲間、家族、社会に価値を届ける会社です。
AIも同じです。
使うことが目的ではありません。
価値を創ることが目的です。
GeminiのGemのようなAIツールを、現場の課題解決、品質向上、教育、顧客価値の創造に本気で活かしていく。
そんなエンジニアが、これからの時代に強いエンジニアだと思います。
エスプリフォートでは、
「できない理由」ではなく、
「どうすればできるか」を考え、
仲間と一緒に前に進むエンジニアを大切にしています。
AIを使って、もっと良い開発をしたい。
お客様にもっと喜ばれる仕事がしたい。
仲間と一緒に成長しながら、技術者として価値を出したい。
そんな想いがある方にとって、
エスプリフォートはきっと面白い場所です。
AI時代のエンジニアとして、ただ作るだけでなく、価値を創る側へ。
私たちは、そんな仲間と一緒に働きたいと考えています。