クラウドとAIを愛する関西SEの備忘録について
はじめまして、ずっきです。いつもありがとうございます。
関西を拠点に活動するシステムエンジニアで、クラウド技術（Google Cloud / AWS）やインフラ構築、そして最近では生成AIを活用した開発（AI駆動開発）に没頭しています。
またブログは、日々のエンジニアリング業務や学習の中で直面した「技術的なエラーの解決策」「資格試験の合格・不合格の記録」「読んだ技術書の書評」などを書き留めている技術ブログです。
初めは自分自身の備忘録としてスタートしましたが、現在では同じように技術に向き合うエンジニアの皆さんの「検索の終着点」になれるような記事を目指して更新しています。
「クラウドを愛する関西のシステムエンジニアの日常」について
1. 生成AI・AI駆動開発（注目のトピック）
今、このブログで最も力を入れているのが、「生成AI×ソフトウェア開発」の領域です。
単に生成AIに質問するだけでなく、AIを開発プロセスそのものに組み込み、コーディングや設計をどう効率化・高度化するかをしています。
特に以下のツールや技術に興味をもっています。
Claude Code / Anthropic
MCP (Model Context Protocol)
GitHub Copilot
最近では、「AIにコードを書かせる」から「AIと共にシステムを構築する」へ。その過渡期における試行錯誤のログをご覧ください。
2. Google Cloud / クラウドインフラ
私のエンジニアとしてのキャリアのベースにあるのは、クラウド技術です。特に Google Cloud に関しては、インフラ構築からサーバーレス構成まで幅広く触れてきました。
「公式ドキュメント通りにやったのに動かない」「謎のエラーが出る」といった現場ならではのトラブルシューティング記事は、このブログの長年のメインコンテンツです。また、VagrantやVirtualBoxを用いたローカル検証環境の構築など、オンプレミス寄りの知見もアーカイブしています。
3. 資格試験・学習レポート（合格・不合格体験記）
エンジニアにとって、資格試験は知識を体系化するための重要なマイルストーンです。
このブログでは、単に「合格しました！」という報告だけでなく、「どのように勉強したか」「試験のどの部分が難しかったか」、そして時には「不合格になった時の反省点」まで公開しています。これから以下の資格を目指す方にとって、私の「体験記」が少しでも役に立てれば幸いです。
Google Cloud 認定資格「落ちた記事」こそ、誰かの役に立つ。
そう信じて、点数や敗因も隠さずに書いています。
4. 技術書・書評
技術の進歩は速いですが、普遍的な設計思想やクラウド、AIエンジニアとしての知識の保管は書籍や動画、セミナーから学ぶことが多いです。
ビジネス書・キャリア論（エンジニアリング組織論、チームビルディングなど）
読んだ本の内容を自分なりに噛み砕き、実務でどう活かせるかを考察したレビュー記事をアップしています。「次に読む本」を探している方は、ぜひ参考にされてください。
5. 開発ツール・備忘録
VSCodeの設定、ターミナル環境、ちょっとしたスクリプトなど、「開発者体験」を向上させるための小ネタ集です。「また同じ設定で迷わないように」書き残したメモが、意外と多くのアクセスの上位にしめています。
最後に
技術の世界は広大で、一人で全てを網羅することは不可能です。しかし、こうしてブログを通じて知見を共有することで、私自身の知識も定着し、誰かのエラー解決の助けになれることを嬉しく思っています。
「AI駆動開発」という新しい波に乗りながら、変わらず「クラウド」を愛するエンジニアとして、これからもアウトプットを続けていきます。
Agent Skills: 賢いAIを育てるために利用しよう！
こんにちは、ずっきです。
今日は、2月にSkillsを利用しよう！と記事を書いてから複数のプロダクトに適用してみて驚くべき成果が見えました。
これは、Agent Skills は、ヤバい！使うとAIがより賢く動くようになる！確信しました。
AIを育てるためAgent Skillsを整理して記事にしたいと思います。
AIを育てるためAgent Skills
1. AIに「何を」ではなく「どうやるか」を教える時代の幕開け
現代の開発者は、極めて深刻な「プロンプトエンジニアリング疲れ」に直面しています。指示を精緻化すればするほどプロンプトは長大化し、貴重なコンテキストウィンドウを浪費する「コンテキスト爆発」を招く。私も去年の2月までは肥大化した指示ファイルに埋もれていました。
この停滞を打破すべく、2025年09月にAnthropicが公開したのが新標準「Agent Skills」です。Claude Code、GitHub Copilot、Cursorといった主要ツールが、2026年に入り相次いでこの規格をGA（一般提供）として採用しました。
これは単なる設定ファイルの追加ではありません。いわば「AIへのマニュアルのパッケージ化」であり、指示（Instructions）と実行（Execution）を完全にデカップリングする、AI駆動開発のアーキテクチャ刷新なのです。AIを単なる道具から、自律的に動く「専門家」へと変革させる、この革新的な仕組みを深掘りしていきましょう。。
2. 『1度書けば、どこでも動く』——エージェント間の壁が消滅した
AIへの指示は特定のプラットフォームに縛られた「使い捨てのプロンプト」でした。しかし、Agent SkillsはSKILL.mdという共通フォーマットにより、驚異的な「ポータビリティ（移植性）」が可能となりました。私のプロダクトは同じスキルを少し変えて移植を繰り返し簡単なプロダクトはスケジュールを2週間の工程を3日に短縮するなど。驚異の生産性を上げています。
Agent Skillsの定義 「Agent Skillsは、エージェントが発見して利用できる指示、スクリプト、およびリソースをパッケージ化したフォルダである」
この標準化の威力は凄まじく、公開からわずか2か月でClaude CodeやCopilot、Cursorに加え主要プラットフォームが対応。もはや特定のIDEに依存する時代は終わりました。
3. 『Progressive Disclosure』——コンテキストの浪費を止める魔法の仕組み
従来のカスタム指示は、常に全ての情報をコンテキストに詰め込む「全ロード方式」でした。これでは指示が増えるほどAIの思考容量（コンテキストウィンドウ）を圧迫し、処理精度を低下させます。Agent Skillsは、「段階的開示」によって、この物理的限界を突破しました。
- Level 1（起動時）: スキル名と概要（description）のみをロード。システムプロンプトへの注入は約100トークンに抑えられます。
- Level 2（マッチ時）: ユーザーの依頼がスキルの説明と合致した瞬間、SKILL.mdの全文（最大5,000トークン推奨）をコンテキストに読み込みます。
- Level 3（実行時）: 必要に応じて、同梱されたスクリプトやリソースをオンデマンドで取得します。
4. 『指示』ではなく『手足』を与える——スクリプト同梱の威力
Agent Skillsが従来の指示ファイルと決定的に違うのは、AIに「知識」だけでなく「手足（実行手段）」をパッケージとして与えられる点です。
「プロジェクトの規約に従ってテストを書いて」と抽象的な指示を出すのではなく、テスト用テンプレートと実行スクリプトを持ったAIエージェントを追加する。
以下のディレクトリ構造が、その「パッケージ」です。
.github/skills/unit-tester/
├── SKILL.md (指示・メタデータ：いつどう動くか)
├── scripts/ (実行スクリプト：テスト実行、カバレッジ計測等)
│ └── run_jest.py
└── assets/ (リソース：プロジェクト固有のテスト雛形)
└── test_template.ts
5. 隠れた勝者ディレクトリ『.claude/skills/』の謎
GitHub Copilotは.github/skills/、Cursorは.cursor/skills/を推奨していますが、ここに「非対称な互換性」が存在します。これは良く思います。
主要ツールの多くが、Anthropicが提唱した.claude/skills/を後方互換として読み込む一方、Claude Code自体は他ツールのディレクトリを読み込みません。つまり、「迷ったら.claude/skills/に置く！これが、汎用的が高い配置先です。
6. 誕生、『エージェンティック・エンジニア』という新階級
Agent Skillsを使いこなし、AIエージェント軍団を指揮する者は、すでに驚異的な成果を叩き出しています。最新の事例では、プログラミング未経験からAIをオーケストレートし、わずか14時間で1.65M行（30プロジェクト分）ものコードを実装したエンジニアが登場。従来比で35倍以上の生産性を誇る彼らは「エージェンティック・エンジニア（Agentic Engineer）」と呼ばれ、年収3,000万円を超える求人もあるらしい。
使用されるモデルも、2026年3月時点でGAとなったGPT-5.4やClaude Opus 4.6へと進化し、より高度な推論とツール実行能力が出てきなともうこの頃です。
7. あなたのナレッジやワークフローを「動くスキル」として資産化しよう
Agent Skillsは、あなたの暗黙知をチームの形式知へと、そして「動く資産」へと変えるための最高のフレームワークです。
まずは一つ、今日から自分専用のスキルを構築してみてください。
GitHub Actionsの複雑なログを解析し、原因を特定するスキル
プロジェクト固有の複雑なコーディング規約を、過去の実装例から自動適用するスキル
もし、あなたのチームの全エースエンジニアが持つ「あの人しか知らない手順」が、すべてAgent Skillsとして配布されたら、開発の景色はどう変わるでしょう。。
「エンジニアの価値は、何を書いたかではなく、AIに何をさせるかで評価される。」
Agent Skillsを利用し開発の ナレッジやワークフローを「動くスキル」にしましょう。
年収3000万は夢じゃない！AIエンジニアの残酷な現実と「選ぶべき」生存戦略
こんにちは！クラウドとAIを愛する関西SEの「ずっき」です。
いつもブログを読んでくれてありがとうごさいます。
今年（2026年）、生成AIの波はさらに加速して、現場では「AIを使えて当たり前」という時代になった。でも、その一方で「ＡＩスキルは磨いているのに、今の会社では給与がちっとも上がらへん……」と閉塞感を感じているエンジニア仲間も多いんと。。実はずっきもその一人。生産性上げたのに給料が。。
実は今、エンジニアの市場は「空前の売り手市場」やけど、働く場所によって「天国と地獄」がはっきり分かれる二極化が進んでいる。今回は、最新データから見える「残酷な現実」と、ＡＩエンジニアが取るべき「最強の生存戦略」を、現場視点で整理してみます！
衝撃の事実：正社員 500万円 vs フリーランス 1,000万円の圧倒的な「壁」
まず、目を背けたらいけない現実から。。
同じ「AIエンジニア」という肩書きでも、雇用形態によってこれだけの差ある。
コミュニティの飲み会で酒回るとまあまあ、無礼講でこの手の話になります。
会社辞めてフリーで案件をＡＩで回して稼いでる。よく聞きます。
|
雇用形態 |
平均年収 |
最高単価（月額） |
メリット |
|
正社員 |
約558万円 |
企業給与テーブルに依存 |
安定性、福利厚生 |
|
フリーランス |
約1,020万円 |
285万円 |
高収入、自由度、案件選択権 |
フリーランスの年収は正社員の約1.8倍。この圧倒的な差は、日本企業特有の「採用のバグ」から生まれてる。さらに、地域格差も深刻で、東京の平均が649万円なのに対して、地方だと392万円。同じAIのスキルがあっても、場所と雇用形態だけで数百万円が「消えてる」のが今の日本の現状。ＡＩ使っていると生産性だしてるのに給料上がらん。ってよく聞きます。また、人事採用担当者からもＡＩエンジニアがこのジレンマで退職するともよく聞きます。「大企業正社員として年収上限に縛られるより、独立・フリーランスとして市場価値をダイレクトに報酬へ変える方が圧倒的に合理的である。」ってことですが。。
特に日本企業は「個人の生産性向上」を報酬に反映しにくい年功序列が残ってるから、どれだけAIで爆速化しても、給料が頭打ちになる構造的な欠陥がある。
新階級の誕生：年収3,600万円を叩き出す「エージェンティック・エンジニア」とは？
最近、AIエンジニアの中でも新しい階層が誕生しました。
それが「Agentic Engineer（エージェンティック・エンジニア）」。
単にチャットでコードを生成するだけの「Vibe Coder」とは次元が違う。MCP (Model Context Protocol) 、などの標準プロトコルを駆使してAIに「手足」を与え、複数のAIエージェントを利用する。最近、はやりのコンテキストエンジニアリングができるエンジニアもその一部だと思います。。
- 驚異の生産性： 実例として、プログラミング未経験からAIを指揮して、わずか14時間で165万行（30プロジェクト分）35倍以上の生産性や。特に作るものを追求し理解するタイプこだわるタイプの方にこの傾向があるようです。
- 年収レンジ： 2,250万〜3,675万円（従来型比で+30〜50%のプレミアム）。
- 求人成長率： 驚異の +986%。これは一般のAIエンジニア（+143%）の約7倍のスピードで需要が膨らんでることを意味してる。
- 学位要件： 従来型はCS学位がほぼ必須やったけど、Agentic Engineerは「ポートフォリオと実績」重視。学位不要で実力勝負できる世界。
- 自動化リスク： 極めて低い。AIが進化すればするほど、それを「指揮する側」の価値が上がるから。
不都合な真実：日本企業の41%はAI導入計画すら「ない」という。古い習慣が大好き！
これだけ夢がある話がある一方で、日本の現場は深刻や。大企業ですら導入率は10%未満。41%の企業はAI計画すら持っていません。なぜこれほど遅れてるのか、そこには「労働契約法」が絡む日本の構造的な壁のせい。
- 解雇規制によるROIの低迷： 労働契約法で解雇が厳しく制限されている日本では、AIで効率化しても「余剰人員」を削減できない。だからAI投資のROI（投資対効果）が出にくい。
- 配置転換による茶濁し： 浮いた人員を配置転換でしのぐから、組織の抜本的な変革が進まない。AI使わない整理対処の社員雇用し続ける。
- 経営層の無関心： 「AIエンジニアを雇った」という事実だけで満足して、業務プロセス自体を変える意思がない。トップがAIに本気でない。
「AIを使えれるようにしました」がゴールになってる現場では、エンジニアの情熱は削られる。これマジで実感です。本気で経営側はAIを使っていく意思ある？と問いかけたい。
最強の生存戦略：ドメイン知識 × AIこそが「代えのきかない」価値を生む
「AIに仕事を奪われる」と怯える必要はありません。最強の戦略は、私たちが持ってる「専門領域（ドメイン知識）」とAIを掛け合わせること
実際、海外ではベンチャーキャピタルに頼らず一人で創業する「ソロファウンダー」が急増しているらしい。これもAIを武器に一人で戦えるようになった証拠だと。「コードを書く時代は終わった。AIエージェント時代へ。AIが進化するほど、AIを指揮できる人間と評価するエンジニアの価値が上がる。」
- 解像度： 現場を知る人だけが、AIで解決すべき「真の課題」を見つけられる。
- 出力の評価能力： AIがもっともらしい嘘（ハルシネーション）をついても、ドメイン知識があれば即座に見抜いて修正指示が出せる。これ重要。
- 希少性の確立： 「医療×AI」「金融×AI」といった掛け合わせこそが、市場で唯一無二の価値を生む。特定ドメインがあると希少価値高める。
年収1000万円を突破する「5つのキャリアパス」比較
今の場所でじっとしてても年収は上がらない。1,000万円突破のための戦略です
|
キャリアパス |
向いている人 |
想定年収レンジ |
|
専門特化型 |
LLMやMLOpsを深く掘り下げたい技術オタク |
800万〜2,000万円 |
|
マネジメント型 |
技術を理解しつつチームを率いたいビズデブ橋渡し役 |
900万〜2,500万円 |
|
外資転職型 |
英語力があり成果主義で最短で稼ぎたい野心家 |
1,000万〜3,000万円 |
|
副業複合型 |
安定を維持しつつ複数の収入源を持ちたい堅実派 |
本業+副業で1,000万超 |
|
独立・起業型 |
自社プロダクトやバイアウトを狙う挑戦者 |
900万〜上限なし |
私は、専門特化型で「クラウド」が特定ドメイン（武器）になると思っています。
結論：変化し続ける市場へ
AIエンジニアは、大きな分岐点に立ってる。
AIにコードを書かされるだけの「Vibe Coder」としていきるか。それとも、MCPを使いこなし、コンテキストを育て、AIエージェントをオーケストレーションして、よりビジネスを動かす「Agentic Engineer」になれるのか。
日本の企業の遅れに絶望するんやなく、その「遅れ」をチャンスと捉えて、特定ドメイン知識という武器を持って市場での価値を高めよう！！
私たちが今日から始める「AIを指揮する」ための第一歩は何？？AIへ利用へ使い方への意識だ。間違っても、AIに仕事を奪われるような意識になるな！変われ！変革しろ！
AIを使って業務効率化！得意なドメインを持ち年収アップ！他人に頼らず業務効率化！
NotebookLMで新しい機能インフォグラフィックを作ってみた！
こんにちは、ずっきです。
最近はAI案件の対応やAI駆動開発に関する検証で日々試行錯誤していますが、今回は新しく「NotebookLM」で、新しい機能が追加されたので、その他の機能も含めてコンテンツを作成してみたので、その作成した内容を備忘録として残したいと思います。
これまで生成AIといえばテキスト生成のイメージが強かったですが、NotebookLMは今やスライド、動画、グラフィックなど、多彩な出力ができるようになっています。自分のブログをソースにして色々と試してみたら、思いのほかよかったで紹介します。
私的なノートブックは紹介はできないのですが。使い方の例に紹介しています。
NotebookLMの出力機能をこのブログサイトをソースに試してみた
NotebookLMにソース（情報源）を読み込ませると、ただの要約にとどまらず、様々な形式でアウトプットしてくれます。
0. まず、生成させる為のソースを検索する。
- 今回は、私のブログのタイトルで検索「DeapResearch」させます。
- 左側にあるStudioを押すだけで数分待つとコンテンツを作成してくれます。
1.ソース追加を選択する
2)主力コンテンツを選択する
1. インフォグラフィック：ブログの歴史を1枚の画像に
ソースに基づいてグラフィックを作成してくれる機能です。
試しに、私のこのブログをインフォグラフィックで生成させてみました。すると、過去の時期から現在の記事までしっかりディープリサーチしてくれて、見事に1枚のグラフィックを作成してくれたんです。
ブログのタイトル通り、「クラウドからAIへの歩み」というテーマを画像にして、これまでの経緯がひと目でわかる記事を作成してくれます。自分のエンジニアとしての軌跡が可視化されるのは、純粋に嬉しいですね。
2. マインドマップ：頭の中を俯瞰する
なんと、マインドマップを作成してくれる機能まであります。
私のブログを読み込ませてみたところ、私がどんな事に関心を持って記事を書いているのか、ブログの関心事項を綺麗なマインドマップにしてくれました。AI推進担当として、自分自身の思考の整理にもぴったりです。
3. スライド：ソースをサクッとプレゼン資料に
ソースの内容を元に、スライドを一瞬で作成してくれます。Gensparkでもスライドを作成してみましたが、どちらもソースの要点を的確に捉えてプレゼン資料に落とし込んでくれるので、スライドの構成をゼロから考える手間が省けて非常に便利です。私は、Gensparkの方が、1ページにまとめる内容を多く詰めれることができるのでこの機能ももっと改善されればいいなと思います。
4. クイズ：認定試験の勉強の強い味方！
個人的に「おおっ！」と思ったのがこの機能。ソースを元に、カード式のクイズを作成してくれるんです。これ、Google CloudやAWSなどの認定試験の勉強とかにめちゃくちゃ使えれるね！と思いました。公式ドキュメントや自分の学習メモをソースにすれば、自分だけのオリジナル問題集がすぐに完成します。絶賛資格勉強中のチームの後輩にも勧めてみようと思います。
4.1 AI知識クイズ（このブログの中身を知らないと解けない）
4.2. AI知識クイズの答え（自分は記事書いたら正解！）
海外の認定試験の問題集をソースにしても同様のクイズ形式を作ることができるかも。
5. レポート：観点を入れた文書作成
ソースの概要だけでなく、特定の「観点」を入れてレポートを作成してくれます。プロジェクトの提案資料や、特定のテーマに絞った調査報告などをサクッとまとめたい時に重宝します。今回は、このブログの全体の記事の概要記事を作成指示してみました。よくまとまっていると思います。
6.データテーブル：
例えば、「生成AI・AI駆動開発に関する技術記事と認定資格のまとめ」といった指示を出すと、過去の記事から該当するものをピックアップして、いい感じで一覧表にしてくれます。情報整理の時間が圧倒的に短縮されます。
誰でも無料で使える！NotebookLMの魅力
これだけ多機能で実用的なNotebookLMですが、一番すごいのは「誰でも利用できる」という点です。さらに嬉しいことに、特別な課金をすることなく、ここまで紹介した機能（スライド、インフォグラフィック、データテーブル、マインドマップ、クイズ、レポートなど）がすべて無料で使えれてしまうんです。
これだけの高性能なAIツールが誰にでも開放されているのは、本当に嬉しいですよね。日進月歩で進化するAIのスピードをリアルに感じる今日この頃です。ちょっとしたことから使ってAIをより身近に感じていただければと思います。
私の使い方の事例を紹介
- 地域の町会活動の資料をすべて写メでノートに追加。過去の資料から次年度の予算ややるべきことなどは、すぐに資料や検索することが可能。
- 幼稚園の規約や案内を全て写メを取りノートに追加。全部チャットで解決する。
- キャンプの宿泊候補出し。過去のブログ記事と過去の工程表から最適な工程をすぐに計画して家族に供する。
- 家族の漢字検定の問題をフラッシュカードで作成する。間違えやすいや傾向などを分析してポッドキャスト、動画にしてテレビで再生して復習させる。
まとめ
今回は、NotebookLMを使ってインフォグラフィックとその他コンテンツを作成して感想をまとめました。特にNotebookLMの多彩な出力機能は、学び続けるエンジニアにとって、学習や業務を効率化するための強力な武器になります。無料で誰でもすぐに始められるので、みなさんもぜひご自身の生活などの備忘録や公式ドキュメントを読み込ませて、色々な出力を試してみてください。
引き続き、AI推進の為、身近でAIを利用すると便利なサービスも発信していきたいと思います！
それでは、また。
最後の挑戦。専門外ドメインの提案書をAIフル活用で作って見えた「AI駆動の限界とリアル」
「最後の挑戦として、AIプロンプト課を作りたい」
そんな熱い思いを上司にぶつけた夏から、少しの時間が経った。
現在、私が直面しているAI駆動開発における最大のテーマは「AIと協業できるか」、それとも「AIに振り回されるか」
今回はその後者として、今週取り組んだ「自分の専門ドメインではない領域の提案書を、AIをフル活用して作成した話」を記事にしてみたいと思う。結論から言うと、AIで前向きに提案書を作成するという非常に価値のある経験ができた一方で、背筋が凍るような不安と「責任の所在」について深く考えさせられる結果となった。
AI駆動による提案書作成ワークフロー
今回、私が構築・実践したAIによる提案書作成のプロセスは以下の通りだ。人間が手を動かす部分を極力減らし、AIのエージェントやスキルを連携させることに注力した。
RFPの解析と抽出
- RFP（提案依頼書）をAgentSKILLでマークダウン化。
- そこから顧客が求める「課題」と「要求」を正確に抽出する。
- さらにAgentSKILLを活用し、RFPにおける問題点や確認すべき事項（Q&A）を重要度別に抽出し、Q&Aシートへ転記するAgentSKILLを実行。
- アーキテクチャ設計と見積もり各領域に対して、RFPに準拠したアーキテクチャ図を生成。
- 生成されたアーキテクチャ図を確認し、AWSの構成図に置き直して自分自身の理解を深める。
- 書き出した内容、アーキテクチャ図、単価表を元に「見積もりSKILL」を実行させ、見積書を生成。
スライド資料の生成
- 提案書のアウトラインに従い、各スライドで求める内容をセクションごとにマークダウンで生成指示。
- 各セクションの内容は、GEMSPARKに生成指示を出させる専用スキルを作成してバンバン生成指示を実行。
- すべてのスライド原案が作成された後、AIにファクトチェックとデザインチェックを専用スキルで指示。
人手による補正と多角的なレビュー
- スライドをPPT（PowerPoint）で出力後、個別の補正作業を人の手で行う。
- 出来上がったタイミングで、「提案書レビュースキル」を実行。
- RFPに準拠しているかを再確認。
- このレビュースキルには、「カスタムエージェント」「PM視点」「経営者視点」という複数の役割を与え、多角的なチェックを実施。
- 提案資料にパワポにノート（説明）をAgentSKILLを作成して追加。
【所要時間】
スライド生成（約30ページ）：約8時間（生成指示出しから初期版完成まで）
人手によるレビュー：約X時間（実現性チェック、矛盾箇所の確認、RFP準拠の確認などど現在も対応中）
直面した壁：「正しく評価できない」という恐怖と責任の所在
AIを駆使することで、たった数日で30ページにも及ぶ提案書のベースが完成した。スピード感は圧倒的だ。しかし、この提案ドキュメントを作成しながら、私はかつてないほどの「成果物を評価できない不安」に襲われていた。
「この提案の責任の所在は、一体どこにあるんだ？」
今回は私の専門ドメインではない領域の提案だった。そのため、AIがもっともらしく出力したアーキテクチャや解決策の「実現性」を、私自身が正確に評価できないのだ。
AIは、人間がイメージできないような生成物であっても、いとも簡単に「できる」ように仕立て上げてしまう。これはリスクだらけの提案だ。
理解できない記載や、実現性が疑わしい箇所は容赦なく削除した。あるいは、「強い推測値に基づく」といったエクスキューズを追記せざるを得なかった。
PPT化された提案書は、デザイン的にはとても綺麗に仕上がっている。しかし、中身をよく見ると、根拠や過去の実績に基づいた意思の通った提案ではないため、言葉の端々から「構築力のレベル（の浅さ）」が透けて見える可能性が高いと感じた。
「これは〇〇な時間だったかもしれない……」
作業中、そんな思いが頭をよぎったのも事実だ。
まとめ：AI時代における「提案」の最適解とは
AI駆動による提案書作成は、確かに短期間で形にすることができた。
しかし、そこにはAI駆動開発と全く同じ課題が横たわっている。
「提案書が本当に正しいのか」
「依頼側の目的や真の課題に即した内容になっているのか」
今回、私はAIにプロンプトを投げて提案書を作成したが、ドメインが違うため生成物の「実現性評価」ができなかった。さらに、RFPを出した顧客との直接の接点がないため、行間にある「依頼側の目的・課題」に本当に即しているかの評価も不可能だった。
これらの経験から得た結論はこうだ。
いくらAIが優秀になっても、提案書作成においては「担当ドメインの有識者が、顧客の意図（コンテキスト）をよく聞いた上で、AIをツールとして駆使して作成すべき」であるということ。専門知識と顧客への共感がなければ、AIの出力はただの綺麗な文字列に成り下がってしまう。
私がAIと振り回して作り上げたこの提案書のベースが、ドメイン有識者によるチェックとブラッシュアップされ、血の通った提案へと昇華されることを、今は唯々祈るのみ。
そして、あと、「AIで提案しよう！」とAIで何でもできると思われている方は、考えなおすべき。
そして、AIプロンプト課（仮）の設立への道は、まだまだ険しく、そして面白い。
【KAG AI Week Days感想】GitHub Copilot は「SKILL.md」を導入しよう！（AI駆動開発がちょっと改善された件）
今週開催されていた「KAG AI Week」にライブで参加したかったのですが、YouTubeで視聴しました。連日興味深いセッションが続いていたのですが、今回はその中からDay 1のGitHub Copilot活用（スキル編）について、私のAI駆動開発の業務視点での気づきと、実際に現場で試してみた結果をまとめたいと思います。
Day 1：GitHub Copilotを使っている人は全員“SKILL.md”も導入してください
まずはDay 1の東口さんセッションから感じた内容です。
以前からCloudeCodeの書籍などで「スキル機能」の概念自体は知っていたのですが、今回のセッションとKAGさんのブログ記事を見て、「これはプロジェクトで即実践すべきだ」と直感しました。
今週、担当している担当案件の環境を適用してみました。
これまで私は、プロジェクトのコーディング規約やテスト方針などをすべて1つのカスタム指示ファイル（Custom Instructions）に記述していました。気づけばその行数は500行近くに。「とりあえず全部書いておけばAIがよしなにやってくれるだろう」と思っていましたが、AIの質が安定しないことはなかったのですが。違った方向に行くことがまれにありました。何かしらの改善ポイントがそこにあるのではないか？と考えも実はありました。そこで、このブログ（KAG AI Week Days さんの動画）を機に、指示ファイル（Custom Instructions）を解体し、タスクごとに「SKILL」へと分割しました。
- 単体テスト実施用スキル
- GitHub Issue起票用スキル
- E2E自動テスト実施用スキル
品質強化を行っているので、このスキルに運用を変更を切り替えました。
「今まで動いていたものが変に動くようにならないか？」という不安もありましたが、結果は良好です。
1. コンテキストウィンドウの節約
VS Code上でのコンテキストウィンドウの使用率が目に見えて減りました。これまでは不要な指示まで常にプロンプトに含まれていたのが、スキル化によって「そのタスクに必要な情報」だけが読み込まれるようになったためです。
2. AIの精度（体感）の向上
不必要なコンテキストの読み込みがなくなったことで、ノイズが減り、AIの回答精度が体感で賢くなったように感じます。チャットでの指示内容に対して、より適切でピンポイントなスキル（指示）を読み込んでいる挙動が見て取れました。
セッション内で「スキルのDescription（説明）は丁寧に記載しよう」というアドバイスがあった通り、ここを分かりやすく記述したことが、AIが適切なスキルを選択するカギになったようです。あと、SKILLがに置き換えたことにより、スキルの例（テンプレート）の場所のフォルダ体系が分かりやすくなってこれもよかったかなと。
3. 私の「SKILL.md」導入の手順
awesome-copilot コミュニティによって作成されたカスタム エージェント、プロンプト、および手順のコレクションにあり、make-skill-templateを使いました。
1. .github\skills\make-skill-template にskillテンプレートをコピーする。
2. スラッシュコマンド/make-skill-template でスキル内容を記載する。
数分でスキルへが作成（置換）が可能です。是非、ご導入してください。
まとめ
AI駆動開発業務のワークフローをKAGさんの情報発信からSKILL導入を決断できました。
GitHub CopilotでAI開発されている方、皆様に「SKILL.md」によるコンテキストの最適化を私もお勧めします。
「エンジニアのための生成AI入門」を再読。ベクトル検索の勘所とAIエージェント実装への道筋
こんにちは、ずっきです。現在担当しているAI案件で、検索機能にベクトル検索とLLMを組み合わせた「AIエージェント」の導入をプロジェクトオーナーに秘密で検討しており、改めて『エンジニアのための生成AI入門』を読み直しました。
Difyなどのツールを触っていると「なんとなく」動くものは作れますが、実務レベルのシステムに落とし込むための設計思想を整理するのに、本書は非常に簡単な説明でイメージがつかみやすかった。忘備録を兼ねて、気になったポイントをまとめます。
「エンジニアのための生成AI入門」を再読
ベクトル検索の理解と「チャンク」の重要性
まず、ベクトル検索のおさらいです。これはキーワードの一致ではなく、内容の「類似度」で検索する仕組みです。
本書でも「VPNがつながらない」という検索クエリに対し、一言一句が一致しなくても「VPN接続ができません」というFAQをヒットさせられる例が挙げられていました。
これを私の好きな「広島焼」で例えてみると、よりイメージが湧きます。
- キーワード検索の場合：
「広島焼」と検索すればヒットしますが、「麺が入った重ね焼きのお好み焼き」と検索しても、「広島焼」という単語が含まれていなければヒットしません。 - ベクトル検索の場合：
「そばが入っていて、混ぜずに層にして焼く料理」と検索したときに、その意味（構造や特徴）が近い「広島焼」のデータを正解として検索することができます。
ただ、ここで課題になるのがチャンク（文書の分割）とインデックスの更新です。
以前Difyで文書登録をしてベクトル検索を試した際、期待した結果がうまく出ないことがありました。本書ではこの適切な分割こそが精度を左右すると説かれており、業務利用に向けては「どう分割して、また更新される文書やデータでインデックスをどのように更新し続けるか」の設計する際に考慮が必要があると感じました。
AIエージェントで実現したい業務フロー
今回、特に注目しているのが「AIエージェント」による提案・自動化機能です。
具体的には、以下のようなエージェント群を検討したいと考えています。
- 構成提案： リソースの利用状況を分析し、最適な構成を提案する。
- 承認代行： 提案内容に基づき、承認依頼をワークフローを自動で実施する。
- 入力促進： リソース登録漏れがある場合、担当者に登録を促す。
ワークフロー自動化： 緊急度に応じて承認フローを動的に切り替え、早期確定させる。
これらを実現するためには、単に質問に答えるLLMではなく、外部ツールを使いこなす仕組みが必要です。
LangChainとLangGraph：状態を持つエージェントへ
ここで重要になるのが LangChain の理解です。
主要コンポーネント（LLMs, Prompt Template, Chain, Tool）を組み合わせることで、複雑な業務ロジックを組むことができます。
- LLMs： OpenAIやAnthropicなど、モデルを切り替えて扱える共通I/F。
- Chain： プロンプト、モデル、パーサー（出力の形式整形）をパイプライン化する仕組み。
- Tool： DBアクセスや計算など、LLMが苦手な領域を外部APIで補完する仕組み。
さらに興味深かったのが LangGraph の解説です。LangChainは基本的に「決められた順序」で処理を進めますが、実務では条件分岐や「やり直し（ループ）」が発生します。
LangGraphは「State（状態）」を持ちながら処理を進めることができ、これはDifyのワークフロー機能の経験からイメージの非常に理解しやすかったです。
- Node： 処理を実行する単位。
- Edge： 処理を繋ぐ矢印。
- State： アプリ全体で共有されるデータ領域。
「予測可能なワークフロー」から、試行錯誤を繰り返す「エージェント」へ移行するためのポイントがここにあると思いました。
エージェント実装のステップとガードレール
エージェントの実装には、有名な ReAct（Reason + Act） パターンがあります。「考えて→行動して→結果を観察する」を繰り返す仕組みです。
本書では、いきなり複雑なものを作るのではなく、ステップを踏むことが推奨されていました。
- Web検索エージェント： シンプルなReAct。
- 状態管理型エージェント： 途中の経過を保持しつつ動く。
- RAG融合型ハイブリッド： 独自知識（ベクトル検索）とツールを組み合わせる。
同時に、運用投入において避けて通れないのがガードレールの話です。
- 無限ループの防止： 上限回数やタイムアウトの設定。
- コスト管理： 予算を意識したトークン制限。
- 権限分離： サンドボックス環境の利用や、「何でもさせない」権限設計。
「ツール（フレームワーク）の進化は激しいので、特定の技術に依存せず、いつでも入れ替えられる柔軟な設計を意識せよ」という教えは、エンジニアとして常に肝に銘じておきたいポイントです。
まとめ
読み直してみて、今のプロジェクトに必要なのは単なる「検索」ではなく、「ベクトル検索で得た情報を元に、LangGraph的なループ制御で意思決定をサポートする仕組み」検討したいなと思いましたしました。
まずはAPIでLLMの実行、そして、シンプルな検索エージェントから着手し、徐々に業務ロジックを組み込んだハイブリッドなAIシステムへと拡張していこうオーナーに提案していこうと思います。
書籍『AI駆動開発チームの作り方・育て方』を読んで
こんにちは。AI推進担当として、日々「どうすれば組織にAIが浸透するか」「チームをどう育てるべきか」を模索しているずっきです。最近、VSCodeでGitHub Copilotを使っていると、驚くことがよくあります。「あれ、いつの間にか知らない機能が追加されている……」と。
例えば、
- Planモード： 指示を出す前に、まずAIにプランを出させてから実行する。
- コンテキストウィンドウのメモリ可視化： AIの短期メモリ「どこまで覚えているか」のメモリ利用率が表示される。
- エージェント選択： クラウドやバックグラウンドなど、VSCode上で実行環境が選べるようになっている。
こうしたアップデートは日常茶飯事です。しかし、これを一人で追いかけ続けるのは、もう限界だと感じていました。また、AI駆動開発の新規メンバーがそのAI駆動開発に順応できない。。そんな時、『AI駆動開発チームの作り方・育て方』という本に出会い、今の悩みの答えがそこにはっきりと書かれていました。
今日は、本書を読んで突き刺さった3つのポイントを、私の実体験を交えて共有したいと思います。
AI駆動開発チームの作り方・育て方
1. 「一人で追うな、チームで追え！」情報の鮮度問題
本書で最も心に刺さったのが、「AIの情報収集は個人ではなくチームで回せ」というメッセージです。
私は技術本を読むのが好きですが、AI関連の本が出るまでには約3か月のタイムラグがあります。今のAI業界において、3ヶ月前の情報はもはや当たり前の知識に近い。最新のキャッチアップは、本や動画よりも「周りからの情報共有」が一番早いというのは、コミュニティでもよく聞く話ですし、私も実感しています。
しかし、私の現場では課題があります。
私が積極的に発信しても、周囲からの共有がまだ少ない。一人でアンテナを張り続けるのは不可能です。本書にある通り、事業部単位で「これ便利だったよ」「こんなアップデートがあったよ」という雑談レベルの共有を仕組み化し、有識者がそれを取りまとめて全体へ還元する。このサイクルを回さない限り、AI駆動のスピード感にはついていけないと痛感しました。これはごく少数ですが、これが出来ている人もいます。
2. 生産性はボトムアップでは上がらない
もう一つ、衝撃的だった一節があります。
「マネジメントの意思決定が遅くては、どんなに現場がAIを駆使しても効率化は生まれない」という指摘です。
これは、現在私が担当している案件を比較すると、嫌というほど分かります。
案件A（自社プロダクト）： 意思決定を完全に任されている。AIと一緒に爆速で構想を形にでき、作業が滞ることがない。
案件B（制約あり）： 契約や工数の兼ね合いで、私に意思決定権がない。仕様の取り決めや着手判断を待つ時間が長く、AIで作業を10分で終わらせても、その後の「待ち」で数日溶けてしまう。
案件C（制約あり）： AI利用をプロンプトエンジニアに依存している。要件定義をAIエンジニアに指示して生成させる。忙しいを理由にAIへの対話をAIで作業を10分で終わらせても指示側のイメージと違い、指示の往復が生まれる。
AI駆動開発において、マネジメントが「足かせ」になる瞬間がある。現場がAIで加速しても、組織、チームの決定スピードがアナログのままだと、AIの恩恵はゼロになってしまうのです。
3. 「分業」よりも「一人で回し切る」スピード感
本書には「チーム内でツールを統一してはいけない」という、一見するとどうかな？と思うタイトルもありました。
その背景にあるのは、「設計から運用まで一人で回し切れるエンジニアを育てる」という思想です。私もこれには大賛成です。理由は単純で、「コミュニケーションコストと作業のコンフリクトの回避」です。
AI駆動だとタスク消化が早すぎて、人間同士で「誰が何をやるか」を細かく分業・調整している時間がもったいない。それよりも、AIをパートナーにして一人がフルスタックに動く方が、圧倒的に効率が良い。もちろん、これにはAIとの協業で間違っている方向に進まない（成果物を評価する力）あること前提になりますが。。
AIへの「Why（問う力）」
私が最近意識しているのは、AIへの「Why（問う力）」です。
AIが出した設計、コードが不安なら、AIエージェントに「なぜこの実装にしたのか」を理解するまで問う。自分の知識として取り込んでからプルリクを出す。
私の会社では、経験浅い若手をフルスタックに物事を考えて意思決定するように育てています。しかし、正直、1〜5年目の若手には責任が重いかもしれません。でも、考えて理解し、コードを承認。マージする、AIを武器に自分で責任を持って進めること。それが、これからのAI時代に求められるプロンプトエンジニアの姿と思い教えています。
終わりに
AI駆動開発は、単なるスキルの問題ではなく「意思決定のあり方」や「チームの文化」の変革そのものです。自社プロダクトを自分の意思で回せている時のあの「全能感」と「スピード感」 を（私はこれを透き通る世界と呼んでいます）いかにチーム全体、そして組織全体に広げていくか。AIは責任を取ってくれませんが、その責任を引き受ける覚悟を持ち、AIエンジニアとしての生産性は次の次元へ行ける。そんな勇気をもらえる一冊でした。
AI駆動開発、AIチーム運用に悩むすべての人に、ぜひ読んでほしいです。
