Geminiで業務効率化のアイデア100個出しから実装まで試行錯誤してみた

Gemini は AI であり、間違えることがあります。

本記事の取り組みには生成AIであるGeminiを活用していますが、出力内容にはハルシネーション（もっともらしい嘘）が含まれている可能性があります。実務に適用する際は、必ず専門家が内容の正確性を確認してください。
生成AIをどのように活用できるのか、具体的な業務にどう落とし込めるのか、その「最適解」を実験してみました。
なお、この記事にも一部生成AIが使われています。

この取り組みの目的

今回は単なる生成AIとの会話ではなく実務で成果を出すための取り組みのため、以下3つの目的を設定しました。

• 生成AIの使い方を学ぶ：望む結果を得るためのプロンプトエンジニアリング技術を学ぶ
• 生成AIの活用方法を知る：膨大な事例から自分の業務に直結しそうなユースケースを選定する
• 実務効率化の体験：Geminiを用いた具体的な工数削減効果を検証し、実業務へ落とし込むための足掛かりとする

取り組み - 概要

アイデアの創出から実装までを以下の4ステップで体系化しました。

• Step 1: 100個の活用事例創出
  Geminiに「AI活用事例100選」を出力させ、幅広い可能性を網羅。製造、マーケティング、ITインフラなど、多角的な視点でAIの適用箇所を洗い出しました。
• Step 2: 実業務への適合性評価
  生成された100のアイデアから、自分の業務課題解決に直結するものをピックアップ。今回は【構成図から設定値の抽出】と【箇条書きメモからマニュアル作成支援】を選定しました。
• Step 3: 実装方法の深掘り
  選定した事例に対し、最適なアウトプット（MarkdownテーブルやTerraformコード）を得るためのプロンプトを構築。単なる質問ではなく、役割定義や出力形式を指定する「ロジックの具体化」を行いました。
• Step 4: 実践と検証
  実際のアウトプットを生成し、その精度を評価。人間による修正時間を加味しても、ゼロから作成する場合と比較してドキュメント作成時間を約60%削減できることを確認しました。

取り組み - 詳細

Geminiのマルチモーダル機能と高度な推論能力を活用した、2つの具体的な実行例を紹介します。

ケース1：インフラ構成図からの設定値抽出とコード化

先ずはGeminiに「この"構成図から設定値を抽出するプロンプト"をテストするために、AWSで標準的なWEB３層構造の構成図を画像で作成して。」と聞くと、Nano Bananaで上の画像を生成してくれました。

画像形式のAWS構成図（Standard Web 3-Tier Architecture）を読み取り、設定値を抽出した上でTerraformコードへと変換しました。

• プロンプトの内容：構成図画像を提示し、「この画像から設定値を抽出し、その後IaCとして利用可能なTerraform形式に変換して」と指示。精度を高めるため、リージョンやサブネットの層（Tier）を明示するよう調整しました
• 生成プロセス（試行錯誤）：当初は汎用的な回答でしたが、「Markdownテーブル形式でAZ（アベイラビリティゾーン）を含めて出力せよ」と条件を追加することで、実務で即利用可能なリストを得ることができました
• アウトプット結果：Geminiは正確に「ap-northeast-1」リージョンや各層のCIDRを特定しました

カスタム指示

【役割】 あなたは高度なネットワークエンジニアおよびクラウドアーキテクトです。
【目的】 添付された構成図画像から、設計に必要な設定値を正確に抽出し、表形式でまとめてください。
【抽出項目】 以下の情報を優先的に探してください。
- デバイス名 / インスタンス名
- IPアドレスプロパティ（IP, サブネットマスク, デフォルトゲートウェイ）
- VLAN ID / サブネット名
- 接続インタフェース（Gi0/0, eth0 等）
　【出力形式】
 　そのままGoogleスプレッドシートに貼り付けられるよう、カンマ区切り（CSV）またはテーブル形式で出力してください。
【注意事項】
- 「わからない」を許容する: 画像が不鮮明で読み取れない箇所がある場合、無理に推測せず、「不明（Unclear）」と出力する。
- 論理的な整合性チェック: 抽出したデータに対し、図面上のセグメントとIPアドレスが論理的に矛盾していないかチェックすること

回答

ご提示いただいた構成図（AWS Standard Web 3-Tier Architecture）から、設計・設定に必要な情報を抽出しました。
論理的な整合性を確認したところ、VPC（10.0.0.0/16）の範囲内に各サブネット（/24）が重複なく収まっており、パブリック/プライベートの切り分けも標準的なベストプラクティスに従っています。
### 抽出設定値一覧（テーブル形式）
| カテゴリ | リソース名 / 項目 | 設定値 / プロパティ | AZ | 備考 |
| --- | --- | --- | --- | --- |
| **Network** | VPC CIDR | 10.0.0.0/16 | - | Region: ap-northeast-1|
| **Network** | IGW Gateway | Internet Gateway | - | インターネット接続用|
| **Subnet** | Public Subnet 1a | 10.0.1.0/24 | 1a | Presentation Tier|
| **Subnet** | Public Subnet 1c | 10.0.2.0/24 | 1c | Presentation Tier|
| **Subnet** | Private App Subnet 1a | 10.0.11.0/24 | 1a | Application Tier|
| **Subnet** | Private App Subnet 1c | 10.0.12.0/24 | 1c | Application Tier|
| **Subnet** | Private DB Subnet 1a | 10.0.21.0/24 | 1a | Database Tier|
| **Subnet** | Private DB Subnet 1c | 10.0.22.0/24 | 1c | Database Tier|
| **Gateway** | NAT-GW-1a | EIP: 13.234.56.78 | 1a |  |
| **Gateway** | NAT-GW-1c | EIP: 13.234.56.79 | 1c |  |
| **Gateway** | VPC Endpoint | S3 (Gateway型/Interface型不明) | 1c | S3-Artifactsバケット接続用|
| **LoadBalancer** | ALB-External | DNS: my-app-external... | 1a/1c | インターネット面|
| **Compute** | EC2 Auto Scaling | Desired: 2, Max: 4 | 1a/1c |  |
| **Compute** | AppServer-1a | m5.large | 1a |  |
| **Compute** | AppServer-1c | m5.large | 1c |  |
| **Database** | Amazon RDS | Multi-AZ Deployment | 1a/1c | PostgreSQL 14|
| **Database** | RDS-Primary | - | 1a |  |
| **Database** | RDS-Standby | - | 1c |  |
| **Security** | SG-ALB | Allow 80/443 (From Any) | - |  |
| **Security** | SG-APP | Allow 80/443 (From SG-ALB) | - |  |
| **Security** | SG-DB | Allow 5432 (From SG-APP) | - |  |
| **Storage** | Amazon S3 | S3-Artifacts | - |  |
---

### スプレッドシート用（CSV形式）

Category,Resource_Name,Property,AZ,Note
Network,VPC CIDR,10.0.0.0/16,-,Region: ap-northeast-1
Subnet,Public Subnet 1a,10.0.1.0/24,1a,Presentation Tier
Subnet,Public Subnet 1c,10.0.2.0/24,1c,Presentation Tier
Subnet,Private App Subnet 1a,10.0.11.0/24,1a,Application Tier
Subnet,Private App Subnet 1c,10.0.12.0/24,1c,Application Tier
Subnet,Private DB Subnet 1a,10.0.21.0/24,1a,Database Tier
Subnet,Private DB Subnet 1c,10.0.22.0/24,1c,Database Tier
Gateway,NAT-GW-1a,EIP: 13.234.56.78,1a,
Gateway,NAT-GW-1c,EIP: 13.234.56.79,1c,
LoadBalancer,ALB-External,DNS: my-app-external.ap-northeast-1.elb.amazonaws.com,1a/1c,
Compute,EC2 ASG,"Desired: 2, Max: 4",1a/1c,
Compute,AppServer-1a,m5.large,1a,
Compute,AppServer-1c,m5.large,1c,
Database,Amazon RDS,PostgreSQL 14 (Multi-AZ),1a/1c,Primary: 1a / Standby: 1c
Security,SG-ALB,Port 80/443 from Any,-,
Security,SG-APP,Port 80/443 from SG-ALB,-,
Security,SG-DB,Port 5432 from SG-APP,-,
Storage,Amazon S3,S3-Artifacts,-,

これらの情報は、TerraformやCloudFormationなどのIaCツールへの入力値、またはAWSマネジメントコンソールでの構築パラメータとして直接利用可能です。

さらに、以下のTerraformコードも生成されました。

回答

AWS 3層アーキテクチャ Terraform構成 (HCL)
ご提示いただいた構成図に基づき、主要なリソースを定義するTerraformのコードを作成しました。この構成は、高い可用性とセキュリティのベストプラクティスに従い、パブリック（Presentation）、プライベート（Application）、データベース（Data）の3つのレイヤーで構成されています。
1. ネットワーク構成 (VPC & Subnets)
VPC CIDR 10.0.0.0/16 内に、各アベイラビリティゾーン(1a, 1c)ごとのサブネットを配置します。
# VPC
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  tags = { Name = "3tier-vpc" }
}

# Internet Gateway
resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.main.id
  tags   = { Name = "3tier-igw" }
}

# Public Subnets
resource "aws_subnet" "public_1a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "ap-northeast-1a"
  tags              = { Name = "public-1a" }
}

resource "aws_subnet" "public_1c" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.2.0/24"
  availability_zone = "ap-northeast-1c"
  tags              = { Name = "public-1c" }
}

# Private App Subnets
resource "aws_subnet" "app_1a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.11.0/24"
  availability_zone = "ap-northeast-1a"
  tags              = { Name = "app-private-1a" }
}

# Private DB Subnets
resource "aws_subnet" "db_1a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.21.0/24"
  availability_zone = "ap-northeast-1a"
  tags              = { Name = "db-private-1a" }
}


2. ロードバランサー & オートスケーリング
外部からのトラフィックをALBで受け、Auto Scaling Group (ASG)によって管理されるEC2インスタンスへ振り分けます。
# Application Load Balancer
resource "aws_lb" "external_alb" {
  name               = "external-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb_sg.id]
  subnets            = [aws_subnet.public_1a.id, aws_subnet.public_1c.id]
}

# Auto Scaling Group
resource "aws_autoscaling_group" "app_asg" {
  desired_capacity    = 2
  max_size            = 4
  min_size            = 2
  vpc_zone_identifier = [aws_subnet.app_1a.id, aws_subnet.app_1c.id]

  launch_template {
    id      = aws_launch_template.app_template.id
    version = "$Latest"
  }
}

# Launch Template
resource "aws_launch_template" "app_template" {
  name_prefix   = "app-server-"
  image_id      = "ami-xxxxxxxxxxxxxxxxx" # Amazon Linux 2023等
  instance_type = "m5.large"

  network_interfaces {
    security_groups = [aws_security_group.app_sg.id]
  }
}


3. データベース (Amazon RDS)
PostgreSQL 14 を使用し、マルチAZ構成で耐障害性を確保します。
resource "aws_db_subnet_group" "db_group" {
  name       = "db-subnet-group"
  subnet_ids = [aws_subnet.db_1a.id, aws_subnet.db_1c.id]
}

resource "aws_db_instance" "db" {
  allocated_storage      = 20
  engine                 = "postgres"
  engine_version         = "14"
  instance_class         = "db.t3.medium"
  db_subnet_group_name   = aws_db_subnet_group.db_group.name
  vpc_security_group_ids = [aws_security_group.db_sg.id]
  multi_az               = true
  skip_final_snapshot    = true
}


4. セキュリティグループ
階層間の通信のみを許可する設定です。
SG名
許可元
ポート
説明
 
ALB SG
0.0.0.0/0
80/443
インターネットからのHTTP(S)
APP SG
ALB SG
80/443
ALBからの通信のみ許可
DB SG
APP SG
5432
AppサーバーからのDB接続

ケース2：ネットワークトラブルシューティング・マニュアルの作成

BGPやVPNの接続トラブルに対応するための、新人エンジニア向け「逆引きマニュアル」を作成しました。

• プロンプトの内容：トラブルツリー形式にすること、具体的なコマンド例（show ip bgp summary等）を含めること、そして抽象的な概念と具体的な操作を両立させることを指示しました
• 生成プロセス（試行錯誤）：VPN接続に関しては、単なるパスワードミスだけでなく、ソースコンテキストにある「Windows Updateの未適用による検疫機能のブロック」といった、現場で発生しがちな具体的要因を含めるよう指示を重ね、精度を高めました
• アウトプット結果：専門知識を要するBGPのトラブルも、以下のような構造化された逆引き表として整理されました

カスタム指示

【役割】 あなたは経験豊富なテクニカルライターです。
【目的】 新人エンジニアが迷わず操作できる「[システム名] の操作マニュアル」を作成してください。
【構成】 以下の項目を含めて、Markdown形式で出力してください。
1. 概要（この作業で何が達成されるか）
2. 前提条件（必要な権限や環境）
3. 手順（ステップバイステップで、注意点を添えて）
4. トラブルシューティング（よくあるエラーとその対処法）態へ更新して再接続

例：BGPトラブル対応メモ

・状況：拠点間接続のBGPピアがEstablishedにならない、あるいはピアは張れているが特定のルートが広報/受信されない。
・まず物理レイヤーとIP疎通の確認。Ping 1.1.1.1（対向IP）が飛ぶか。TTLの設定ミスでeBGPが届かないパターンが多い。マルチホップ設定を確認。
・AS番号の不一致。設定ミス。自組織と相手組織のASが逆になっていないか。
・ピアが「Idle」や「Active」の状態なら、TCP 179番ポートがFWでブロックされていないかチェック。
・「Established」なのに経路が来ない場合、prefix-listやroute-mapのフィルタ設定を確認。denyしすぎ。
・広報側：networkコマンドで指定したルートがルーティングテーブル（RIB）にそもそも存在するか。存在しない経路は広報できない。
・受信側：soft-reconfiguration inboundが入っていないと、反映にクリアが必要になる。
・BGPテーブル（show ip bgp）を見て、ネクストホップが到達可能（Accessible）か確認。ネクストホップが解決できないとRIBに載らない。
・これでも不明ならログを収集してエスカレーション。

回答

# BGP接続トラブルシューティング・マニュアル
## 1. 概要
本マニュアルは、拠点間接続においてBGPピアが確立されない、あるいは期待したルートが広報・受信されないトラブルを迅速に解決することを目的としています。物理層からプロトコル層まで順を追って確認することで、ダウンタイムを最小限に抑えます。
## 2. 前提条件
* 対象ルータへの特権実行モード（`enable`）でのアクセス権限。
* 対向拠点とのネットワーク構成図（AS番号、IPアドレス、期待される広報ルートの一覧）。
* コンソールまたはSSHによるCLI操作環境。
---
## 3. トラブルシューティング・フロー（診断ツリー）
以下のフローに従って、現在のステータスを確認し、適切なステップへ進んでください。
mermaid
graph TD
    Start[トラブル発生] --> Q1{ピアの状態は?}
    Q1 -- "Idle / Active" --> Step1[物理疎通 & TCP 179確認]
    Q1 -- "Establishedだが経路なし" --> Step2[フィルタ & RIB確認]
    
    Step1 --> Q2{Ping疎通あり?}
    Q2 -- No --> Action1[物理/IPレイヤーの復旧]
    Q2 -- Yes --> Action2[AS番号/eBGPマルチホップ設定確認]
    
    Step2 --> Q3{自拠点の広報ミス?}
    Q3 -- Yes --> Action3[networkコマンド & RIB存在確認]
    Q3 -- No --> Action4[prefix-list / ネクストホップ解決確認]
---
## 4. 解決手順（ステップバイステップ）
### ステップ1：物理・IPレイヤーの疎通確認
BGPメッセージが届く状態にあるかを確認します。
1. 
**対向IPへの疎通確認** 
* `ping [対向ピアIP]` を実行。
* **注意点:** 応答がない場合は、IFの状態やルーティングを確認してください。
2. 
**TCP 179番ポートの確認** 
* ファイアウォール（FW）等でBGPの通信（TCP 179）が遮断されていないか確認します。
3. 
**eBGPマルチホップの設定** 
* 直接接続されていない相手とeBGPを張る場合、TTL制限で届かないことがあります。
* `neighbor [IP] ebgp-multihop [TTL数]` の設定を確認してください。
### ステップ2：ネイバー設定の整合性確認
ピアが「Established」にならない原因を特定します。
1. **ステータスの確認**
* コマンド: `show ip bgp summary`
* **Idle:** 設定ミスや物理断。 **Active:** 接続試行中（応答なし）。
2. 
**AS番号の照合** 
* 自組織と相手組織のAS番号が逆になっていないか、設定値に誤りがないか再確認します。
### ステップ3：経路広報・受信の確認
ピアは張れている（Established）のに、ルートが届かない場合の対応です。
1. 
**広報側：RIB（ルーティングテーブル）の確認** 
* `network` コマンドで指定した経路が、そもそもルータ内のルーティングテーブルに存在するか確認します。
* **原則:** RIBにない経路はBGPで広報できません。
2. 
**受信側：ネクストホップの解決確認** 
* コマンド: `show ip bgp`
* ステータスが **Accessible（到達可能）** か確認。ネクストホップへ到達できない経路は、有効なルートとしてRIBに載りません。
3. 
**フィルタリング設定の確認** 
* `prefix-list` や `route-map` で意図せず `deny` していないか見直します。
---
## 5. トラブルシューティング（逆引き集）
| 事象 | 主な原因 [cite番号] | 推奨アクション |
| --- | --- | --- |
| **ステータスがIdleから動かない** | FWでのTCP 179ブロック 

 | セキュリティグループやACLの設定を変更 |
| **ピアがActiveを繰り返す** | AS番号の不一致 

 | `router bgp [AS]` と `neighbor remote-as` を再確認 |
| <br>**経路が一つも受信できない** | soft-reconfiguration inbound未設定 

 | 設定を入れるか、`clear ip bgp * soft` で更新 |
| **特定の経路だけが届かない** | フィルタ設定のミス 

 | route-mapの条件式（permit/deny）を精査 |

> **[重要] エスカレーションの判断**
> 上記手順をすべて確認しても解決しない場合は、ログ（`show logging`）を収集し、速やかに上位エンジニアへエスカレーションしてください。 

まとめ

今回の体験を通じて、Geminiが単なる「チャットボット」ではなく、アイデア創出から実装までつなげてくれることを体験できました。

1. 一気通貫の価値：100の事例から最適なものを選び、コード生成やマニュアル作成までを一つのツールで完結できる効率性
2. 実務適用のリアリティ：ハルシネーションを前提とした「人間による最終チェック」の工程を組み込めば、現状でも十分に実務投入可能なレベルだと感じました

今後は Google Apps Script (GAS) を組み合わせたWorkspace連携による自動化を行ってみたいと思います。