『いちばんやさしいAIエージェントの教本』を読んで、リアルに感じるエンディングの時。
こんにちは、ずっきです。
今回は、『いちばんやさしいAIエージェントの教本』を読んだ感想と、現在私が現場で実践している「AI駆動開発」のリアルを交えて、これからのエンジニアの働き方について書いてみたいと思います。
- はじめに
- 2025年の「AIエージェント」、「MCP」ブームを振り返って
- AIエージェントを使いこなすための「構造化」と「記憶」
- 人間がやるべきこと、AIに任せること
- 最後に「卒業」「エンディング」の時とこれからの夢
はじめに
この本を読んで改めて確信したのは、「AIエージェントとの協業こそが、これからの業務のスタンダードになる」ということです。
AIエージェントは「自律的に動けるデジタル同僚」
まず、この本ではAIエージェントを以下のように定義していました。
- 「ゴールを理解して一緒に行動するAI」
- 「自律的に動けるデジタル同僚」
これ、すごくしっくりきます。
どれも共通しているのは「言われたことだけやる」のではなく、「目的（ゴール）に向かって自律的に動く」という点です。
私は現在、AI駆動開発においてコーディングエージェントを活用していますが、まさにこの感覚です。私がやるのは「指示の概要（目的）」と「役割（ロール）」を定義するだけ。具体的な道筋を細かく指示しなくとも、AIは目的を理解し、自律的に動いてくれます。日々の業務でそのタスク消化能力の凄まじさを実感しています。
この本の中で「AIで失業は本当に起こるのか？」という問いに対し、「人は創造的な仕事に移行する」という結論が書かれていました。
これについて、私自身の話を少しさせてください。
実は私は、去年の6月に「自分でコーディングすること」をやめました。
理由はシンプルです。私が書くよりも、AIの方がより良い実装を短時間で行えるからです。そこで私は、エンジニアとしての役割を「コードを書く人」から、より創造的なポジションへと意図的にチェンジをしました。
それは、「AIを利用するためのガイドライン策定」であったり、社内の意識改革を進める「AI推進」であったり。今では社内で「AIおじさん」として、新しいAIとの業務の進め方を啓蒙する役割を担っています。
2025年の「AIエージェント」、「MCP」ブームを振り返って
本の中で、AIエージェントをより使えるようにするためには「AIをToolとして活用すること」が重要だと説明されていました。
- ブラウザ操作（Compute User Agent）
- チケット操作（Github Issue）
- テスト実施（PlayWrite）
これらは、人間が手を動かさなくても、AIが必要な時にコマンドを打つだけで実行できる開発です。記憶に新しいと思いますが、2025年にはMCP（Model Context Protocol）開発が激しく流行りました。 私も当時、AIができないことを実現できるMCPに心を奪われました。AIに「手足」を持たせることで、単なるチャットボットから、本当の意味での「エージェント」へと進化した年でした。
AIエージェントを使いこなすための「構造化」と「記憶」
本には、AIエージェントが働きやすくするためのポイントとして、以下が挙げられていました。
- 目的を明確にする
- 業務フローを構造化する
- 情報の所在を整理する
- 判断ルールを明文化する
また、アーキテクチャの視点では「長期記憶」の重要性にも触れられていました。短期記憶には限界があるためです。私の開発現場でも、コーディングエージェントには必ず「ステアリングファイル（引継ぎノート）」と「Github Issue」を出力させています。これを長期記憶として残すことで、過去の作業をいつでも思い出させることが可能になっています。
人間がやるべきこと、AIに任せること
もちろん、AIにも「推論の誤り」や「コンテキストの理解不足」といった課題はあります。だからこそ「全ての作業は見ないが、初期の思考プロセス（方向性）は確認する」というスタンスが重要だと私は考えています。
そして、AIに頼ることで「自分で考える力が衰える」という落とし穴があることも自覚しなければなりません。
コマンドラインで「あれ、どうだったっけ？」と迷うことがリアルに増えました。後輩にコマンドを打ちながらその流れを説明する際に忘れるので恥ずかしいですが。。
私は、AIファーストでありながらも、「AIがやった後に、人間は何を決めるのか」という意思決定の力、そして「Why」を説明できる力が必要不可欠になります。
最後に「卒業」「エンディング」の時とこれからの夢
AIエージェント同士が連携し、複雑な業務をこなす時代になると思います。よりAIに置き換えられ、人間はより想像性が必要な業務へのシフトは進むと思います。私は、今の会社での「開発エンジニア」という役目を終えた時が、今の会社での私の役目が終わる時だろうなと思っています。それは、AIが進化して出来ることが進化するに従い、卒業は近いなとも感じています。
その後の夢・・
実は、「広島焼の店」を開いて、細々とやっていきたいんです（笑）。AIには絶対にできないこと。それは、「美味しい食べ物」と「楽しい時間」を直接提供すること。そんな温かい場所（店）を開きたい。それまでは、この頼もしい「AIエージェント（相棒）」と同僚たちと共に、もう少しだけ最前線で走り続けるつもりです。
▼『いちばんやさしいAIエージェントの教本』おすすめです。
▼広島焼の店を始めるならこんな店を開きたい！
『コンテキストエンジニアリング』を読んで。LLMの挙動をする「文脈」の正体
今回は、AIエンジニアにとって必須スキルとも言える概念を扱った書籍、『コンテキストエンジニアリング』の感想をまとめたいと思います。
コンテキストエンジニアリング
この本を手に取ったきっかけ
私がこの本を購入しようと思ったきっかけは、日々の業務の中で「AIへの入力とは、すなわち『コンテキスト』そのものではないか？」と感じる場面が増えたからです。
LLM（大規模言語モデル）を使っていると、単に命令文を投げかけるだけではうまくいかないことが多々あります。ネットでこの本を見つけたとき、そこには一般的な「AIへのプロンプト指示術」だけでなく、コンテキストの収集や、肥大化する情報の対策までが記載されており、「まさに今必要な知識だ」と思い予約購入しました。
コンテキストエンジニアリングの本質
コンテキストエンジニアリングを「様々な入力が混在するコンテキストをいかに磨き上げて、LLMにとってより良い状態に維持するか」の重要なスキルだと定義しています。
単にプロンプトを書くだけではなく、入力情報全体をエンジニアリングするという視点の説明がありました。
コンテキストの正体と「ロール」の定義
本書を読んでまず整理されたのが、「ロール（役割）」についてです。
DifyやGoogle AI Studioなどのツールを使っていると、よく system や user といった項目を目にしますが、本書では、以下のように明確に定義されています。
- system / developer: LLMの挙動を制限するための指示など。
- user: ユーザーからの入力。
- assistant: LLMからの出力。
- tool: 外部ツールから取得したデータ。
特に重要だと感じたのが、「system」や「developer」の役割です。ここにサービス固有の指示を事前に与えておくことで、もしユーザー側からロールに反する指示（悪意ある入力など）が出されたとしても、AIが乗っ取られる「Jailbreak」を防止になります。
また、対話履歴として user と assistant のやり取りをそのまま差し込むと、LLMが過去の内容に引継ぎてくれます。
LLMのへの指示のポイントを理解する
コンテキストエンジニアリングにおいては、LLMという指示の特性（癖）を理解することが不可欠です。本書で紹介されていた以下のポイントは、業務でもすぐに意識したい内容もあり。ポイントを押さえて再度理解したいと思います。
1. Lost in the middle（入力位置による認識精度の差）
これはよく聞く話ですが、LLMは指示文の「最初」と「末尾」に強く注意を払い、「中盤」の指示は見落としがちになります。そのため、重要な指示やキーワードは、必ず冒頭か末尾に配置する。私は、冒頭に指示の内容とそして末尾に受け入れ条件を入れてタスクの指示の内容を言葉を変えて記載します。
2. 過去の会話の揮発性とキャッシュ
最近のLLMプロバイダは「コンテキストのキャッシュ機能」を提供し始めています。エンジニアリングの観点からは、キャッシュの境界を意識し、「頻繁に変わらない部分（静的）」と「流動的な部分（動的）」をなるべく分離して設計することがコストと速度の面で重要だと説かれていました。
3. 言語間の性能格差
私も普段感じていることですが、日本語で指示を出すと、英語に比べてトークン消費量が増えたり、誤変換による精度のブレが生じたりします。
対策として、「可能ならシンプルな日本語を使う」「トークン消費を抑えたい指示（箇条書きの指定など）は英語で行う」といった使い分けが推奨されていました。
Reasoningモデルという新しい波
本書では、最近話題の「Reasoningモデル（推論モデル）」についても触れられていました。これは、回答を出す前に「思考の過程（Chain of Thought）」を出力しながら、コンテキストを充実させ、論理を磨いていくモデルです。最終出力までの待機時間は発生しますが、思考中にツール（MCPなど）の仕様を確認したり、ロングコンテキストを解釈したりする際には非常に強力な武器になります。
指示プロンプト開発の基礎
具体的にどう「指示」を書けばよいのか。実践的なテクニックが紹介されていました。
プロンプト記述の基本
- 構造化する: マークダウン記法を活用し、可読性を高める。
- 英語の活用: トークン効率や精度向上のために英語を混ぜる。
- 否定形を避ける: 「〜しない」よりも「〜する」と書く。
- Whatを意識: HOW（やり方）よりもWhat（何をしてほしいか）を明確にする。
- 変数の活用: マークダウン内に外部からの変数を埋め込む
指示プロンプトの基本構造（テンプレート案）
- プロンプトを作成する際は、以下の要素を網羅すると良いでしょう。
- Role: 役割の定義。
- Task: 目的、背景、なぜやるのか、スコープ、完了条件。
- Output Format: 出力形式やスキーマ定義。
- Guidelines: ガイドライン。
- Constraints: 禁止事項。
- User Info: タイムスタンプやユーザー属性（誰への回答かを明確化）。
- Knowledge Base: 参照知識。
- 精度向上のための技法
精度を高めるためのテクニックとして
- Few-Shot Prompting: 指示の中に「例（Example）」を含める。
- Chain of Thought (CoT): 「ステップバイステップで考えて」と指示し推論過程を出力させる。
- 再帰修正: 一度出力させた後、その内容を評価・修正させる指示を追加する。
- 指示のRecall: 出力形式の中に、あえて指示内容を復唱させるような項目を作り、指示忘れを防ぐ。
- Structured Output: 中間出力として得たい内容をJSONなどで構造化して指定する。
おわりに
「コンテキストエンジニアリング」は、AIに指示を出すだけでなく、AIが最大限のパフォーマンスを発揮できるように情報を整理して質を維持することだと感じました。本書には、これ以外にもRAGにおけるコンテキスト整備や、AIエージェントによる作業の自動化についても詳しく書かれていましたが、長くなりますので、そのあたりはまた次回の記事でまとめたいと思います。
AI開発に携わる方、プロンプトの精度に悩んでいる方には、非常に学びの多い一冊です。是非読んでみてください。All night AI With Context Engineering!!
「生成AIのプロンプトエンジニアリング」を読んで！
こんにちは。ずっきです。
週末にリフレッシュして、少しは人間らしい感性を取り戻した私です。
しかし、休みが明ければやはり私はAIモードに戻ります。（笑）
先週、鉄板の前でプロ（職人）の広島焼を食べてなのか、改めて自分のプロンプトエンジニアリングを見つめ直したくなりました。
そこで手に取ったのが、『生成AIのプロンプトエンジニアリング』という書籍。
普段、職場で後輩とあーだこーだ言いながらAIを使っている私ですが、改めて体系的に学んでみると、「知っていること」と「意外とできていなかったこと」が浮き彫りになりました。
今回は、この本で紹介されていた「プロンプトの5つの原則」と、私にとって最大の気づきだった「品質評価（ブラインドプロンプティング）」について、備忘録を兼ねてまとめます。
プロンプトエンジニアリング「5つの基本原則」
本書では、生成AIから良質な回答を引き出すために、以下の5つの要素が重要だと説かれています。
せっかくなので、前回のブログで感動した「広島焼」を題材に、具体例を挙げて解説してみます。
① プロンプトの方向性を示す（Direction）
AIに「誰として」「どう振る舞ってほしいか」という役割（ペルソナ）を与えます。
悪い例：
「お好み焼きの作り方を教えて」
良い例（方向性あり）：
「あなたは大阪・肥後橋にある広島焼の名店『ながい』の店長です。家庭のホットプレート（フライパン）でも再現できる、キャベツの甘みを最大限に引き出した広島焼の焼き方を教えてください」
結果：Gemini Pro3
② 出力形式を指定する（Format）
人間が使いやすい形（CSV、表、コードなど）で出力させます。
具体例：
「必要な材料と分量を、買い出しリストとして使えるようにMarkdownのチェックボックス形式で出力してください」
結果：Gemini Pro3
③ 例を示す（Examples / Few-shot）
具体的な「入力」と「理想の出力」のペアを見せることで、AIの精度を一気に高めます。
具体例：
「以下の食材の下処理方法を回答してください。
例）キャベツ → 千切りにする（太すぎると火が通りにくい）
例）豚バラ肉 → 鉄板に広げてカリッと焼く
本番）中華麺 → ？」
結果：Gemini Pro3
④ タスクを分解する（Task Decomposition）
いきなり答えを出させず、思考のプロセスを踏ませます（Chain of Thought）。
具体例：「いきなり完成形を教えるのではなく、『生地を敷く工程』『具材を重ねる工程』『ひっくり返す工程』の3ステップに分けて、それぞれのコツを解説してください」
結果：Gemini Pro3
⑤ 品質の評価をする（Quality Evaluation）
出力された回答が適切かどうかをテストし、評価するプロセスです。
……さて、これは、今まで読んだ本にはない基礎プロンプトです。
「品質評価……？ やって自分の頭では？」と。
正直に言うと、①〜④の「方向性」「形式」「例示」「分解」については、業務上のやり取りや、これまでの経験則で「そりゃそうだよね」と理解していました。これらは、いわば「美味しい料理を作るためのレシピ」です。
しかし、5つ目の「品質評価」については、完全にアレでした。
これまでの私は、良さそうなプロンプトを書いて、それっぽい回答が返ってきたら「よし、OK！」と満足して工程を進めていました。
つまり、「料理を作って出しっぱなしで、味見をしていない」（マジか！）状態だったのです。
「ブラインドプロンプティング」という気付き
本書では、この品質評価の手法の一つとして「ブラインドプロンプティング（Blind Prompting）」が紹介されていました。
名前だけ聞くと難しそうですが、要するにこういうことです。
ブラインドプロンプティングとは：
作成したプロンプトに対して、テストデータを使って指示と応答確認を繰り返し、「本当にその成果物で大丈夫か？」をテストと改善を繰り返すこと。
例えば、「広島焼の焼き方」を教えるプロンプトを作ったとします。
ここで満足するのではなく、あえて「麺をパリパリにしたい場合は？」「キャベツが焦げやすい場合は？」といった様々な入力（テストケース）を投げかけ、プロンプトが正しく機能するかを検証する。そして、ダメならプロンプトで修正指示する。
この「作って終わりではなく、叩いて成果物を鍛える」プロセスこそが、エンジニアリングの本質だったのです。
前回の「ながい」の店長もそうでした。
私が「麺はパリパリが好き」と言えば、「じゃあ長めに焼きましょうか」と即座に対応（調整）してくれました。あれは、長年の経験による「焼き方を客の好みに合わせて修正」が頭の中に完成されているからこそできる神対応なんだと。
具体例：「麺をパリパリにしたい場合は？」「キャベツが焦げやすい場合は？」
結果：Gemini Pro3
※店長は、コツ3で対応してました。が、せんべいを作る（笑）
結果：Gemini Pro3
※店長は、コツ③フタを使っていました。
具体例：ながい焼にはオオバとからしが必要です。買い出しリストを見直してください。
※食べたときに感じた和（あっさり感）は確かに和からしだと思います。
※オオバ 分量２～３枚であっていると思います。
まとめ：プロンプトは「対話」の積み重ね
今回の読書を通じて、私はプロンプトエンジニアリングを「指示（コンテキスト）で正しい成果物を一回で近づける技術」に意識が行き過ぎていたことに気づきました。
実際はもっと寄り添うような。ジャブ打つような。
「指示を出す → 結果を見る → 評価する → 指示を直す→ 評価する → 指示を直す」
という、地道なAIとの対話（殴り合い）の繰り返しこそが、最強のAIアシスタントを作る近道なのだと思います。
これからは、業務でAIを使う時も、週末に家で広島焼を焼く時も、「今の出力（焼き加減）、本当にこれでキャベツは蒸れてるか？」と確認（評価）するフェーズを大切にしていきたいです！広島焼はキャベツの蒸れ確認が本当に重要！
さて、今夜も後輩に負けないよう、夜更かしするか！！
Let’s stadying on book ! Yes, All Night AI!
リフレッシュ！後輩と「広島焼 ながい」へ！鉄板サイコー！
こんにちは。
普段は業務でAIのことばかり考え、昼休みですらランチを忘れるほどAIへの指示に没頭している私です。最近の私は、正直に言って「AI」ばかりを考えすぎていました。
そんな私の異常（電車を乗り間違える）を察知したのか、見かねた家族から「たまには外で飲んできたら？」という、提案を受けました。
確かに、アウトプットの質を高めるには、良質なインプットとリフレッシュが必要です。というわけで、金曜日の夜、職場の後輩を誘って、久しぶりに夜の街へと繰り出しました。
「広島焼 ながい」鉄板サイコー
肥後橋の広島焼 ながいへ
私に付き合ってくれたのは、職場の後輩の通称「GPH」。
私の職場では、成長を期待して彼を「グレート・プロンプト・エンジニア・名字（GPH）」（笑）と呼んでいます。
普段、私は彼とよくランチに行きますが、そこで彼が教えてくれたのが、今回の目的地である「広島焼 ながい」でした。
職場の近くに本格的な広島焼が食べられる店がある。
私は店に行く前から、「食べるなら絶対に鉄板の前。店長が焼いている姿、お店の焼き方を見ながら食べたい」とも漏らしてしていました。
暖簾をくぐると、そこには私の望み通りの光景が広がっていました。
熱気を帯びた大きな鉄板。そして、その前で手際よくコテを操る店長。
私たち一番入口に近い特等席（カウンター）に滑り込みました。まずは乾杯です。
普段はディスプレイ越しにしか顔を合わせないことも多い最近です。
コロナ禍以降、在宅ワークが標準となり、オフィスで顔を合わせて仕事をする機会がめっきり減りました。だからこそ、こうして肩を並べて鉄板前に飲むビールは格別です。
GPH（後輩）は、少し照れくさそうに「実は、職場の先輩とこうやって飲みに行くの、初めてなんですよ」とこぼしました。それを聞いて、誘ってよかったなと思いましたね。AIがどれだけ進化しても、このコミュニケーションだけは代替できません。
広島の味覚と、止まらない会話
広島焼が焼き上がるのを待つ間、鉄板焼きのつまみをいくつか注文しました。
- がんす（広島名物の魚のすり身フライ）
- こんにゃくのガーリックポン酢和え** （ながいの名物一品）
- 広島産のカキ
アルミホイルに乗せられて提供されるスタイルが、また臨場感があって良い！
特にこんにゃくのガーリックポン酢は、ニンニクのパンチが効いているのにポン酢でさっぱりしていて、ハイボール（ヒゲのハイボールかな？）やビールが進みます。
アルコールが回るにつれて、話題は広島焼の焼き方から地元の話へ。
お互いの地元である九州の話で盛り上がり、気づけばAIの話なんて一秒もしていませんでした。
こだわりの「ながい焼」と店長の神対応
そして、いよいよメインディッシュの登場です。私たちが頼んだのは、お店の名前を冠した「ながい焼」。これは通常の広島焼とは一味違います。たっぷりの大葉（オオバ）を使用し、ソースに「からし」を和えた、あっさり系の大人の広島焼です。
出来上がった「ながい焼」は、まさに絶品。
カウンター席の醍醐味である「店長との会話」が発生しました。私が「広島焼の中華麺は、パリパリに焼くのが好きなんですよ」と話すと、店長は「それなら、少し長めに焼いて麺をパリッとさせましょうか？」と提案してくれました。
まさに、こちらのカンターの醍醐味！店長ありがとう！さらに驚いたのが、そのサイズです。私がカウンター越しに、いかに広島焼が好きか、家で作る時はどうしているかなど、素人のこだわりを熱弁（笑）していたせいでしょうか。
店長が笑いながら、「見られていると緊張しますね！間違って1ランク大きく焼いてしまいました。サービスでいいです食べてください！」と言ってくれたのです。
これには私は歓声を上げました。エンゲージメントを高めるUX（顧客体験）設計が完璧すぎます！笑
パリパリに焼かれた麺の食感、キャベツの甘み、そこに来る大葉の爽やかな香りと、からしソースのピリッとした刺激。コテで切り分けてGPHと語りながら食べるこの時間は、何物にも代えがたい至福のひと時でした。
追加で月見焼を注文！ネギ盛りに卵を乗せた広島焼です！焼いてる工程を見てさらに会話を楽しみます。
まとめ：店長の気づかいと鉄板に癒されて
店を出る頃には、私の頭の中にあった「AI」の文字は完全に消え去り、アルコールで陽気に満たされていました。
帰り際、店長に「迷惑じゃなかったですか？また、食べたいですがカウンター予約できますか？」と尋ねました。すると店長は、「とんでもない！電話で予約していただければ大丈夫ですよ。ぜひまた来てください」と笑顔で答え、他の店舗のチラシまで渡してくれました。
業務効率化やAIへの指示の話ばかりをしていた、、毎日でしたが、この金曜日は人とコミュニケーションをとり一緒に鉄板を囲むは最高だ！リフレッシュができた気がします。手間ひまかけて焼く工程、店員さんとの何気ない会話、後輩との会話。これこそが、人間の活動におけるAIに真似できない関係の作り方だとおもいます。そして、私は、今週末の楽しみが一つ出来ました。
「自宅で『ながい焼』を再現し、家族に振る舞うこと」です。
今週末は小麦粉とキャベツのレイヤー構造構築（広島焼作り）に全力を注ぎたいと思います。GPH、そして「ながい」の店長、最高の週末、本当にありがとうございました。
また必ず、カウンターを予約して伺います。
【お店情報】
広島焼 ながい
Instagram：https://www.instagram.com/hirosimayaki_nagai/?hl=ja(https://www.instagram.com/hirosimayaki_nagai/?hl=ja)
「生成AI時代のソフトウェア開発」を読んで感じた、期待と内容のギャップ！
「生成AI時代のソフトウェア開発」を読んで感じた、期待と内容のギャップ
「生成AI時代のソフトウェア開発」という魅力的なタイトルに惹かれ、ネットで購入した一冊。しかし、目次を眺め、読み進めるうちに、私が求めていた内容とは少々異なる方向へと進んでいることに気づきました。今回は、この本を読んで感じた率直な感想をブログ記事としてまとめたいと思います。
IDEベースの開発ツール評価への疑問
まず、私が特に疑問を感じたのは、IDEベースの開発ツールの紹介と評価についてです。本書では、特定の指示を与えた際の各ツールの結果を比較していますが、どうにもその評価方法に違和感を覚えました。
「そのツール独自のコンテキスト設定をしないで評価をしている」これが、私の正直な感想です。各IDEにはそれぞれ独自のコンテキスト設定やモデルがあり、それらを適切に設定せずに一律の指示で評価するのは、ツールの真の性能を測っているとは言えないのではないでしょうか。あたかもIDEの評価をしているようで、実際にはIDEに組み込まれたAIモデルの評価に終始しているように感じられました。ブラウザベースのGPTやGeminiも同様の評価対象となっていましたが、これらのツールの特性を十分に考慮した上での評価とは言い難く、読み始めてすぐに「この本は、IDEを正しく評価しているのではないかな感じました。
AIというよりも、AIが組み込まれた製品・サービスの紹介中心
バグ検出、自動テストと章は続きますが、ここでも「生成AI時代のソフトウェア開発」というよりは、AIが組み込まれた既存の製品やサービスの紹介が中心という印象を受けました。もちろん、それらのツールがAIを活用していることは間違いありませんが、読者が期待するのは、もっと踏み込んだAIの活用事例や、AIがどのように開発プロセス全体を変革していくのかという深掘りした内容ではないでしょうか。
最後の章に感じた「？」。そして、見えてきた提言
最後の章では、成功した導入事例がいくつか紹介されています。しかし、その後のまとめ「生成AIを活用したソフトウェアの未来について」の記述には、さらに「？」が浮かびました。
「AIで置き換えられない仕事の紹介（ATMが普及しても窓口業務はなくならないなどの事例）やエレベータ運転士（日本だとエレベータガール）は、時代と共に亡くなったとか。よくわからない例が並びます。」
なぜここで、これらの例が挙げられるのか、読者としては理解に苦しむ部分でした。生成AIがもたらす未来を語る上で、もう少し直接的に、そして建設的な議論が期待されるところです。しかし、その後に続く提言には、納得できる部分もありました。
「これからのAI時代に必要なのは、プランニングとアーキテクチャ、レビューと品質管理、コラボレーションとコミュニケーションだ」
そして、「これからはAIツールを常に最新のツールを把握しておくべきだ」という内容です。この点に関しては、私も同意見です。AIが進化する現代において、単なるコード生成に留まらず、より上位の概念であるプランニング（プロジェクト計画）やアーキテクチャ設計、そして人間による品質管理とチーム内の円滑なコミュニケーションの重要性が増していくでしょう。また、日々劇的な進化するAIツールを把握し、適切に活用していくことは、これからのソフトウェア開発者にとって不可欠な意識であることは間違いありません。
まとめ：AIツール紹介されている本
最終的にこの本を読んでの感想は、ソフトウェア開発で利用できる様々なツールの紹介と、そのツールの最新情報を把握することの重要性を改めて認識させてくれた、という点に集約されるかと思います。
期待していたような、生成AIがソフトウェア開発の全工程を根本的に変革する具体的な方法論や、その深掘りした考察は少なかったものの、現状のAIを活用したツール群を知る上では、一定の価値がある一冊だと言えるでしょう。
「生成AI時代のソフトウェア開発」というタイトルが示すような、より未来志向で実践的な内容を期待していた私にとっては、若干の物足りなさを感じる読書体験となりましたが、最新の開発ツールの知識取得や比較で触れるきっかけとしては良いかもしれません。この本を読んでどのような感想を持たれるのかな。Amazonのレビュも気になります。
『経営者のための生成AI組織的活用の教科書』から学ぶ！AIを組織に定着させる具体的な方法
先日、『経営者のための生成AI組織的活用の教科書』を読み、AIを組織で活用していく上での具体的な課題解決策や、事例に共感を受けました。特に印象的だった点をいくつかピックアップしたいと思います。
■Nano Banana Create
- 上司がAIを使わなければ、チームは動かない！
- 「考えてから使う」のではなく「使ってみてから考える」
- 案件で必要となる社内文書の作成
- 専門家ではない人を講師にする意外な効果
- 成功事例を真似ることから始めるAI活用
- RAGで自社用AIを育成する
- AIが変える現場の常識：プレゼン動画をAIで作成！！
- プロンプトもAIに生成させる！ユースケース展開を加速
- まとめ
上司がAIを使わなければ、チームは動かない！
本書で最も共感したのは、「社長(上司)が率先してAIを利用しなければ、チームはAI利用が定着しない」という一文です。どんなに言葉でAI利用を促しても、上司自身が使っていなければ、その発信に説得力がないのはもちろんのこと、具体的な利用イメージや組織に浸透させるための方法を部下はイメージできません。
「AIを利用を指示する社長(上司)は、果たして自身の作業をAIで効率化しているのか？」という疑問は、私自身も常々感じていたことです。もし効率化しているのであれば、それを積極的に発信し、部下に具体的な事例を示すべきである点は共感した。
本書では、週に一度AI利用に関する会議を開き、利用内容や改善点を指摘するMTGを設けることを推奨していました。このような場を通じて上司がAI利用の方向性を示し、繰り返し実践することで、現場目線でのAI定着化、利用意識が根付いていくというのです。AI利用をもっと意識させるためにも、このような取り組みは積極的に検討すべきだと感じました。
「考えてから使う」のではなく「使ってみてから考える」
もう一つ、非常に印象的だったのが「考えてから使うのではなく、使ってみてから考える」という提言です。まさにその通りで、私もAIに触れてみて初めて「なるほど、こんなことにも使えるのか！」と気づくことが日常茶飯事です。
AI利用を阻む大きな要因の一つに、「新しいことを覚えるのはしんどい」「AIは難しそうだ」という意識があります。この意識を払拭させることが、利用促進の第一歩だと本書は説かれていました。
AIは触ってみないと分からない。まず、使ってみるから始めるべきです。
例えば、日常業務でAIを活用できる場面は無数にあります。
- 議事録の作成
- 提案書のアイデア出し
- 新しい事業計画の構想
- メールの返信
案件で必要となる社内文書の作成
これらをAIで効率化できた事例を上司が部下に示すことで、「よし、私もAIを使って率先して効率化の事例を共有しよう」という意識が芽生えるはずです。
本書では、利用を促すためのユニークな方法も紹介されていました。例えば、冷蔵庫の写真をAIに添付してレシピを作成させるなど、一見「不純な動機」でAIを使わせることで、まずはAIに慣れさせることを重視していました。とにかく利用回数を増やすことで、質は後から追いついてくる、という考え方です。
また、AI利用者のログを取ることで評価指標にしたり、日々の利用目標（例えば1日5回）を設定したりすることも、定着化には有効だと書かれており、非常に実践的だと共感した。
専門家ではない人を講師にする意外な効果
本書で特に驚きだったのが、「AIに詳しくない人を社内の講師にすること」でした。
専門家ではない人だからこそ、難しい言葉を使わずにAIのことを説明できる。これにより、聞き手は親近感がわき、利用促進につながるというのです。AIを使わない人の言葉が分かる人だからこそ、そのハードルを下げることができる、というのは意外でした。
成功事例を真似ることから始めるAI活用
AIの具体的な利用方法として、「すでに成果が出ている方法をそのままマネする」ことが勧められていました。
- 学習コストが少なくて済む。
- 成功の確率が高い。
- 応用への基盤となる。
これは非常に理にかなっています。さらに、縦横でノウハウを共有することで、応用が利くAI利用へと発展させられると。
経営計画書に「生成AIパスポート取得を促す」といった具体的な施策を盛り込むことで、組織全体の生成AIリテラシー向上にも繋がるという提言も記載がありました。
RAGで自社用AIを育成する
RAG（Retrieval Augmented Generation）でAIを自社用に育てる、という提案も非常に魅力的でした。自社の情報をもとにRAGを構築し、それをテンプレートとして資料作成などに活用できれば、業務効率は飛躍的に向上すつとのことです。
AIが変える現場の常識：プレゼン動画をAIで作成！！
本書で紹介されていた「AIが変える現場の常識」の中で、私が特にやってみたいと思ったのが「プレゼンを動画で作る」という内容でした。これまで、システム開発に携わる私たちにとって、動画の作成は工数や動画クオリティの面で限界があると感じ、敬遠していました。思いついてもやれないアプローチです。
しかし、AIを活用すれば、例えば提案書からその提案内容を訴求するような動画を簡単に作成できるというのです。これにより、お客様の理解を深め、より具体的に提案をイメージしてもらうことが可能になるのではないかと考えました。
私は動画クリエイターではありませんが、プロンプト次第で生成AIに動画のシナリオや構成を依頼できるはずです。この新たな提案方法は、これからのビジネスにおいて強力な武器になると感じました。
プロンプトもAIに生成させる！ユースケース展開を加速
最後に、組織的活用法の事例として紹介されていた「プロンプトをAIに生成させてユースケース展開を加速」という点に、大きな興味と共感を覚えました。
Difyのようなツールを使えば、システムプロンプトをAIで生成することが可能です。プロンプトテクニックを知らない人でも、AIの特性に合ったプロンプトを瞬時に生成できるのです。これは、まさに「AI活用におけるAI活用」と言えるとおもいます。
自社のAIガイドラインでは「プロンプト例がないと指示ができない」という声もよく聞きます。しかし、このプロンプト自体もAIに生成させれば、精度の高い指示文が瞬時に手に入るのです。
私自身、Difyでアプリを作成する際にプロンプト生成器を利用し、指示文の作成時間を大幅に短縮しています。簡単に書いたものが、思考の連鎖形式のプロンプトに置き換わるのを見た時には、「こんな書き方ができるのか！」と驚きました。
プロンプト自体をAIに生成させるという発想は、AI活用のハードルを下げ、組織全体での利用促進に大きく貢献するこれは間違いないと思います。
まとめ
『経営者のための生成AI組織的活用の教科書』は、AIを組織に定着させるための具体的なステップと、実践的なヒントが満載の一冊でした。この本で得た学びを活かし、私もできるところから、初めてAI活用を推進していきたいと思います。
クラウドと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駆動開発」という新しい波に乗りながら、変わらず「クラウド」を愛するエンジニアとして、これからもアウトプットを続けていきます。
