生成AIの5層のエンジニアリング_公開版

2026年6月時点の整理 生成AIの 5層のエンジニアリング プロンプト → コンテキスト → ハーネス → ループ → グラフ

はじめに なぜ「エンジニアの使い方」の話をするのか 01 試行錯誤が一番オープン IT系、特にWeb界隈は「やってみた」を公開する文化がある。生成AIの使い方で、利用者側の工夫が最も蓄積されている分野 02 名前が付いて流行っている ○○エンジニアリングという呼び名で整理されているので、それを借りて紹介する ※ 取り上げられているそれぞれに、明確な世界共通の定義はありません。 ※ 2026年6月時点の話。その後のローカルLLMブーム（Qwen3.8シリーズ、DeepSeek V4 など）やGPT-6 Astraの話題は織り込んでいません。

前提 非エンジニアの使い方と、エンジニアの使い方 対話型インターフェイス API利用 チャット画面で使う（主に非エンジニア） プログラムから呼び出す（エンジニア） • モデルに送るデータの準備は自分でやる • 送るデータの操作（前工程）を自動化できる • 返ってきた結果の加工・チェックも自分でやる • 受け取ったデータを後工程で処理できる • 1回のやりとりで完結する • 何回も自動で回せる この後の話は、ほとんどが「自動でくり返せる」ことを前提にした世界の話です

全体像 5層のエンジニアリング Prompt Engineering プロンプト Context Engineering コンテキスト Harness Engineering ハーネス Loop Engineering ループ Graph Engineering グラフ = 口頭で指示 = マニュアル化・自動化 = 仕組み化 = タスクの一任 = チームを組成して依頼 5層は独立したものではなく、下の層が前の段階を取り込んでいたりします 出典：X @akshay_pachaar

1 Prompt Engineering プロンプト・エンジニアリング = 口頭で指示 やること つまずきポイント • モデルへの「聞き方」を工夫する • 入力の出来で品質が上下する • 良い言い回しを探す • • 「Let's think step by step」と入れるだけで成績が上がった、といった事 例が有名（※今は逆効果） Prompting Inversion：モデルが賢くなるほ ど、凝ったプロンプトより素朴な指示のほう が成績が良くなる逆転が起きる

参考 モデル自体も進化していく プロンプト：「日本の少子化の原因を3つ挙げて」に対する“思考”の変化 2024年9月 2025年7月 2026年4月 Qwen2.5-7B Qwen3-8B Qwen3.6-27B 思考なし 考えてから答える 構成を設計してから書く いきなり答えを書き出す。内容は整って いるが、考えた形跡は残らない 「まず生活費、次に労働文化…」と自分 で候補を出し、抜けがないか自問してか ら答える ブレストし、上位3つを選定し、下書きを3 回推敲し、要件を満たしたか最終確認ま でする 工夫がモデル側に吸収されたり、モデル自身の性能向上でこれまでの工夫が通用しなくなることがある

参考 ｜ 思考ログ全文 Qwen3-8B（2025年7月）の思考ログ ※ Qwen2.5-7B（2024年9月）には思考プロセスがなく、いきなり生成結果を出力します。 なるほど、ユーザーは日本の少子化の3つの原因について尋ねているんだな。ちょっと考えて 第三に、家族に対する社会的な支援の問題がある。日本の福祉制度は、他のいくつかの国ほ みよう。日本が深刻な人口減少に直面していることは知っているし、これにはいくつかの要因 ど充実していない。例えば、育児休業制度が限定的であり、保育に対する政府の支援も少な が絡んでいる。 い。このため、親が仕事と家庭の両立を図ることがより難しくなっている。 まず、日本における生活費の高さ、特に都市部での生活費の高さが大きな問題だと思い出 待てよ、他にも要因はあるだろうか？ もしかすると、高齢化そのものが少子化の結果と言える す。人々は住居費に多くのお金を費やしており、それが家族を持つことを難しくしている。教育 かもしれないが、ユーザーが求めているのは結果ではなく原因だ。だから、今挙げた3つのポイ や医療を含めた子育ての費用も、この負担に拍車をかけている。 ントで十分なはずだ。これらが最も一般的に挙げられる理由かどうかを確認しておいた方がい 第二に、日本の労働文化は非常に過酷だ。長時間の労働や、家庭生活よりもキャリアを優先さ せられるプレッシャーが、結婚や出産の遅れにつながりかねない。「過労死」という概念も、健 康上の懸念から子どもを持つことに対する人々の意欲に影響を与えている。 いかもしれない。リアルタイムの情報にアクセスすることはできないから、既存の知識に頼るこ とにしよう。そう、その3つの要因は、主要な原因として広く認識されている。

参考 ｜ 思考ログ全文 Qwen3.6-27B（2026年4月）の思考ログ ① 1. リクエストの分析 • トピック：日本の少子化（日本社会）の原因。 • 要件：原因（要因・理由）を正確に3つ挙げること。 • 言語：日本語。 3. トップ3（最も影響力があり、包括的なもの）の選定 • れない、仕事を辞めざるを得ない」という側面もある。 • 経済的要因：子育てコスト、雇用の不安定さ（非正規雇用）、賃金の停滞。 • 性別役割分担／社会構造：育児・家事の不平等な分担、働く母親の「セカンドシフ ト」（家庭での二重労働）、仕事と家庭の両立の難しさ。 • 価値観・ライフスタイルの変化：独身主義の好み、晩婚化・非婚化、旅行や趣味 の追求（DINKS）、子供の優先順位の低下。 • 制度的・構造的要因：保育施設の不足（待機児童）、教育費。 選定2：家事におけるジェンダー不平等。これは日本特有の構造的問題。女性が キャリアを諦める、あるいは男性の収入が低くて家庭を持てない ── これらが 2. 日本の少子化の原因のブレインストーミング • 選定1：経済的制約。お金は大きな要因。「お金がかかる」だけでなく、「休暇が取 少子化や非婚化につながる。 • 選定3：価値観・結婚トレンドの変化。「子供を欲しがる欲求の低下」や、従来の家 族形成よりも自己実現を重視する動きは、明確な社会学的トレンドである。

参考 ｜ 思考ログ全文 Qwen3.6-27B（2026年4月）の思考ログ ② 4. コンテンツのドラフト作成（反復的な洗練） ドラフト1（頭の中のアウトライン） • 経済：賃金が安く、子供にお金がかかる。 • 女性の仕事：家事と仕事の両立が難しい。男性が手伝わない。 • マインドセット：結婚したくない、子供がほしくない。 ドラフト2（よりフォーマルな日本語） • • 3つの理由を挙げたか？ はい。 • 日本の少子化に関するものか？ はい。 • トーンは適切か？ はい、情報提供として客観的である。 6. 最終的な出力を構築する • 理由1：経済的制約／雇用の不安定さ。 • 理由2：家事の不平等な分担／労働環境。 原因。 • 理由3：価値観の変化／ライフスタイルの変化。 ジェンダーギャップ：家事育児は女性が担う風潮。女性が出産で仕事を辞めざる 7. 最終出力の構築 価値観の変化：晩婚化や結婚しない人達が増えた。自己実現を優先するように • 見出しを明確にする。 なった。 • 読みやすさのために太字を使った箇条書きにする。 • 各ポイントに簡単な説明をつける。 ドラフト3（最終出力に向けた推敲と構成） • ポイント1：経済的不安。「雇用形態」（非正規）と「コスト」に焦点を当てる。 • ポイント2：女性の就業と出産・育児のジレンマ。労働の不均等な配分に焦点を当 • • 経済的要因：子育てにかかる費用が高いこと、正規雇用でない若者の多いことが を得ない。 • 5. プロンプトに対する最終確認 （ドラフト作成中の自己修正） てる。 最初は「保育所の不足」を別のポイントとして入れようと考えたが、それは「職場環境・構造的 ポイント3：結婚・出産の価値観の変化。晩婚化、非婚化、価値観の多様化。 問題」に該当し、ジェンダーの不均衡という議論と相性が良い。1つの強いポイントとしてまとめ る方がよい。

2 Context Engineering コンテキスト・エンジニアリング = 仕事を依頼するやり方のマニュアル化・自動化 やること つまずきポイント • モデルに「見せる情報」を設計する • • 参考資料を貼る、前提を伝える、自分のプロフィールを渡す — こうした 作業を自動化する 不要なものまで載せると、かえって品質が 落ちる • ある例では、RAGで読み込んだ35,000トーク ンのうち関連していたのは約6%。残り94%が 応答を劣化させた • 具体的にはRAGやMCPの整備

3 Harness Engineering ハーネス・エンジニアリング = 仕組み化 やること つまずきポイント • 前提として「モデルが何時間も自分で動く」世界の話 • • モデルの外側にツールと制約を置く 過剰なガードレールで、モデルが何もできな くなる • カスタム指示やファイルを常備しておく • 単純にコストが増える • プロンプトで済む話を、環境側で直してしま う

4 Loop Engineering ループ・エンジニアリング = タスクの一任 やること つまずきポイント • 繰り返し自動で回す • • 一度指示したら、あとは勝手に調べて検証してくれるようにする できないタスクなのに回り続けて、トークンだ けを溶かす可能性がある

5 Graph Engineering グラフ・エンジニアリング = チームを組成して依頼 やること つまずきポイント • 複数のループを協調させる • コストが爆増する • 調査係・執筆係・校正係のように、複数のAIを組み合わせたワークフ ローを作る • organized nonsense：同じモデルのエージェ ント同士が馴れ合って、構造だけ立派で中 身が間違っている • 過剰に分解してしまう ※ 他社や他チームへの依頼ではなく、自分でチームを組成するのがポイントです。

まとめ 非エンジニアができること インプットを工夫する アウトプットを確認する 生成AIに渡すプロンプトと前提情報を、伝わる形に整える 返ってきたものを鵜呑みにせず、しっかりチェックする でもこれって、普通の仕事の進め方ですよね。 生成AI相手であっても、普通に仕事をしましょう

Appendix 参考・クレジット おすすめの記事 Claude Codeで「AI部下10人」を作ったら、勝手にバグ直して「違反は切腹」ルールを追加してきて、オレは適当にしゃべるだけに なった https://zenn.dev/shio_shoppaize/articles/5fee11d03a11a1 5層の出典 X（旧Twitter）ユーザー akshay_pachaar による整理 https://x.com/akshay_pachaar/status/2081089131808243999 壁打ち：Claude Opus 4.6 ／ 翻訳：Nani ／ 整形：Claude Opus 5

• https://zenn.dev/shio_shoppaize/articles/5fee11d03a11a1
• https://x.com/0xCodez/status/2064374643729773029