🤝

Context Engineering がカバーしていない領域「Human Context」を開拓する

に公開
llm
promptengineering
生成 AI
AIエージェント
contextengineering
idea

サマリー

  • Context Engineering が現状カバーできていない空白地帯がある
    • Window Context：コンテキストウィンドウまわり
    • Agent Context：エージェント設定まわり
    • Human Context：何を渡すかという「何」自体をどうつくるか ★ここ
  • Human Context は言語化の営みであり、万人が行うのは現状難しい
    • Human Context Engineering と題して工学化し、再現性を持たせて誰でもできるようにしたい
    • そのためには言語化、読み書き、創造など、IT とは異なる分野も持ち込んで統合が必要
    • もちろん「そもそもコンテキストとは何か」の捉え直しも必要
  • 整備はこれからだが、現時点で見えている方向性と一部内容を提示する

はじめに ～コンテキストって何？～

コンテキスト（Context）は文脈という意味であり、押さえるべき背景や前提その他情報全般を指します。

元々ビジネス用語として通用していましたし、タスク管理の界隈でも深堀りされていました（興味あれば拙作を参照）。どちらかと言えば、知る人ぞ知る横文字の扱いだったかと思います。

それが生成 AI の台頭に伴って、当たり前のように使われるようになりました。LLM にはコンテキストウィンドウという概念があり、これを超えたインプットができない点はよく知られています。最近では Prompt Engineering の延長として Context Engineering も謳われています。

問題提起 ～多義語すぎない？～

一方で、バズワードとまでは言いませんが、意味が曖昧な言葉の一つでもあると感じます。

全体像を整理したいなと思いました。

3 層で整理できる

というわけで、整理してみました。3 つありそうです。

1: コンテキストウィンドウ

まず Context Engineering が指しているのは、主にはコンテキストウィンドウです。ウィンドウに何をどのように詰め込むかを調整します。フォーカスが「コンテキストウィンドウ」であることは、提唱元とされる各所の定義からも明らかでしょう。

Andrej Karpathy 氏（該当ツイート）:

Context engineering is the delicate art and science of filling the context window with just the right information for the next step.

（コンテキストエンジニアリングとは、次のステップに必要な適切な情報でコンテキストウィンドウを満たすための、繊細な技芸であり科学である）

Addy Osmani 氏（Context Engineering: Bringing Engineering Discipline to Prompts）:

Context engineering means constructing the entire context window an LLM sees – not just a short instruction, but all the relevant background info, examples, and guidance needed for the task.

（コンテキストエンジニアリングとは、LLM が目にするコンテキストウィンドウ全体を構築することを意味する。単なる短い指示ではなく、タスクに必要な背景情報・例・ガイダンスをすべて含める）

IntuitionLabs の解説記事（What Is Context Engineering? A Guide for AI & LLMs）:

The practice of designing systems that decide what information an AI model sees before it generates a response.

（AI モデルが応答を生成する前に、何の情報を見せるかを決めるシステムを設計する営みである）

2: エージェントの設定

次に LLM コールをラップする「エージェント」と呼ばれる概念があり、これもある程度決まったパラメーターをもっています。たとえば Anthropic の Agent SDK reference - Python では次のように定義されています。

@dataclass
class AgentDefinition:
    description: str
    prompt: str
    tools: list[str] | None = None
    model: Literal["sonnet", "opus", "haiku", "inherit"] | None = None
    skills: list[str] | None = None
    memory: Literal["user", "project", "local"] | None = None
    mcpServers: list[str | dict[str, Any]] | None = None

このような「エージェント設定」もまた、コンテキストとして言及されることが多いと思います。 Context Engineering として、こちらのエンジニアリングを思い浮かべる人もいるでしょう。そもそも実務的にはコンテキストウィンドウも、エージェント設定も、どちらもエンジニアリングの対象です。「コンテキスト」という言葉一つで、これらを全部扱えてしまいます。

3: 本来の意味でのコンテキスト

さらに、私たちが持つ文脈――本来の意味でのコンテキストもあります。

私はコンテキストの主語には AI と人間の二つがあると思っていて、ここまでは AI にとってのコンテキストを指していました。もう一つ、人間にとってのコンテキストもある、というか忘れてはならないと思うのです。

たとえば私自身ですと、以下のようなコンテキストがあります:

  • 私個人のパーソナルな文脈
    • 信念や価値観
    • 中長期的なマイルストーンや今週今月レベルのスケジュール
    • 直近抱えているイベント
  • 仕事に関する文脈
    • プロジェクト A
    • タスクフォース B
    • 所属部門 C
  • 居場所ごとの文脈
    • 会社員としての私
    • 日曜日の私
    • ゲーセンに遊びに来たときの私

と、このように考えていくと、おおよそ 3 種類くらいありそうだとわかります。

3 層モデル

出揃ったので、改めて整理します。

次のように整理しました:

層 主語 定義
Human Context 人間/組織 目的に照らして解釈・選択・整形された情報
Agent Context エージェント そのエージェントを成立させる構成の束(モデル・ツール・メモリ・ポリシー)
Window Context コンテキストウィンドウ 推論時に LLM が実際に読むトークン列

実際の流れは次のとおりで、下流ほど低級になります。

[Human Context]     解釈・キュレーション
      ↓
[Agent Context]     エージェント構成への組み込み
      ↓
[Window Context]    実行時のウィンドウ充填
      ↓
    LLM推論

各層の例も軽く取り上げましょう:

  • Human Context:
    • (現状無し)
  • Agent Context:
    • Agent framework, MCP, Skills
  • Window Context:
    • RAG, Compaction, Memory

現状 Context Engineering が指しているのは Window と Agent だけです。

まだ整備されてない Human Context

3 層モデルで捉えたとき、Human Context の部分は未だ整備されていないとわかるはずです。よく言われる表現は次のようなものです。

MCP は配管を整備したが、何を流すかは未だ整備されていない。

後者の「何を流すか」こそが Human Context である、と私は考えます。Human と名付けたのも意図的で、私たち人間の文脈こそ大事にしよう、AI に任せるのはいいが主導権は人間にあるのだ――とのメッセージを込めています。

正論は通じないと言いますが、正論は文脈を踏まえないからでしょう。それは AI も同じで、いくら AI が優秀で、最高の出力を出したとしても、文脈を踏まえないと納得できません。しかし AI は現時点でエスパーではなく、こちらの文脈は汲み取ってくれないし、データを整えて AI から引き出せるようにしただけでも足りない。

私たちが、私たちの文脈を自ら言語化しなければならないのです。

言語化の力が要ります。言語化を何度も持続させる必要もあります。AI が扱える形式で置いてあげないといけません。人と聞いたり話したりするのではなく、読み書きを使わねばなりません。上手く読み書きするには、あるいはさせるには、書き方から構造まで調整しなければなりません。

ではエンジニアなら通用するか？といわれると、実はそうでもないのです。AI に渡す情報の仕組みをつくったり、事前加工したりといったことは得意ですが、それだけです。言語化自体にはあまり縁がありません。そもそも言語化せずにソフトウェアをつくって動作させたら勝てる世界です。ドキュメント作成に慣れたエンジニアは多いですが、これも技術的な情報を形式的に書く営みであり、言語化というよりは翻訳あるいは穴埋めです。

ならば言語化が得意な作家や哲学者なら良いかというと、そうでもない。今度はテクニカルな部分でつまづきます。Markdown 一つにも苦戦するでしょう。

まだあります。自分たちの置かれた現状や問題の本質を言語化するには、もう一つ、ある種の特殊能力が求められます。GTD のような自己管理メソッドとマインドフルネスを習得したライフハッカーや、事業開発に携わるプロデューサーやクリエイター、あるいは組織に道を示す組織長などはお手の物だと思います。しかしエンジニアや作家や哲学者はこれらを知りません。

と、ここまで（雑なくくりですが）3 つの分野が出てきました。これらすべてを使います。Human Context は学際的にアプローチせねば整備できないもの と考えます。だからこそ未整備なのだと思います。私はこれを Human Context Engineering と呼びたい。

Human Context Engineering

AI に何を入れるかの「何」をつくる営み――これを Human Context Engineering と題して、エンジニアリング（工学）として整備したい。なお、ここで工学とは、辞書的定義として出てくる「数学や自然科学を応用した」ではなく、体系的に整理して再現性を持たせたり運用可能にしたりするといった意味です。整備すれば誰でも使えるようになりますし、AI に詳しくない他分野の人も合流しやすくなるはずです。

というわけで、以降では、私が考える Human Context Engineering を少しお見せします。私ならこんな風に捉えていくかな、という例です。本格的な整備の前に、まずは記事として第一案をラフに出したものです。皆さんも自分ならどう捉えるかを考えてみてください。

原則：コンテキストは動的

まず Human Context は動的なものである、としたいです。

以下の二つを定義して、

  • 静的な情報源（Static Source）
  • 動的なコンテキスト（Dynamic Context）

コンテキストとは、静的な情報源を解釈して生み出したものである とします。もっと言えばコンテキストとは解釈であり、コンテキストは生きているということもできます。開発者向けには「コンテキストとは実行結果である」もわかりやすいかもしれません。

この見方は皆さんの体感にも一致すると思います。たとえば以下のような静的な情報源がコンテキストかというと、違うだろうからです。

  • 資料：ナレッジやリファレンス、その他資料のような「参照」されるもの
  • 中途成果物（アーティファクト）：個人やチームが日頃残している作業メモその他ファイル
  • 観念：暗黙知というほどではないが、頭の中または日頃の運用として現れる信念や文化

資料と中途成果物については、AI に読ませる筆頭ではありますが、通常読ませるだけでは足りません。そもそも Window に入り切らないし、入ったとしても雑多になりすぎます。また観念については、少々独自の解釈かもしれませんが、頭の中にあって「他者に通じない」状態を指しています。当然ながら AI に読ませることはできません。

Human Context は AI に与えることが前提なので、これら静的な情報源だけでは足りないことがわかります。むしろ静的な情報源をいかに解釈して、その結果を渡すか、との話になるはず。

コンテキストを育てる

「コンテキストは動的」原則に従うと、コンテキストは育てることができるとわかります。

[Static Source] ---(interpret)--> [Context]
                                  [Context]
                                  [Context]
                                  ...

育て方は二つあるはずです。

  • 解釈の洗練：解釈（interpret）の仕方を洗練させる
  • 静的化：筋の良いコンテキスト（Context）を、静的な情報源（Static Source）に置く

やり方自体は従来の Context Engineering でカバーできています。たとえば解釈として「プロフェッショナルのピープルマネージャーとして振る舞いなさい」と役割を指示すれば、その専門知識を使ってくれます。Prompt Engineering ですね。あるいは静的化として、Claude Code Skills のスキルの中にプロンプトとして埋め込むとか、references/ を掘って静的な情報源として置いておいて、スキルのプロンプトから条件分岐的に参照する等も鉄板です。

しかし、Human Context として扱いたいのは、そのようなテクニックではありません。むしろ「何を置くか」の「何」をつくりたいのです。筋の良いコンテキストをつくりたい。そうして、筋の良いコンテキストを静的化した状態で、さらに解釈して、もっと良いコンテキストをつくって――のようにして成長していきたい。これを育てると言っています。

Content → Code から Content → Context → Code へ

コンテキストを育てると何が嬉しいのでしょうか。成果物の質を上げられます。開発者が出す成果物は主にソフトウェア（特にその実態たるコード）ですので、これを例にして、もう少し説明します。

「コンテキストは動的」原則により、成果物の出し方が変わります。

これまで:

[Content]     ドキュメントその他データベース（Static Source）
      ↓
[Code]        コードや設定ファイル

これから:

[Content]     ドキュメントその他データベース（Static Source）
      ↓
[Context]     Contentを解釈したもの（本当の意味でのコンテキスト）
      ↓
[Code]        コードや設定ファイル

従来は Content を踏まえて Code をつくっていました。AI 時代でも Content を用意しておいて、LLM に引かせて理解させた上でつくってます。コンテキストという言葉も、この Content を指していました。つまりコンテキストを静的なものと捉えていた。しかし、このように Content をそのまま使ったり、その場の思いつきで解釈するだけでは質が上がりません。どうやらコンテキストの質そのものを上げる営みが要りそう です。

しかし、Context Engineering なるジャンルは（Window や Agent など）技術的な部分ばかり掘っていて、この営みに接続していない。だから Human Context という第三の軸を定義しました。

Content と Code の間に、もう一つ層があるのです。Context と書いています。Content という静的なソースをそのまま使うのではなく、筋のいい解釈をつくる。その上で Code に反映する、と、そう考えるのです。これは静的なコンテキストではなく、動的なコンテキストと言えます。

Human Context の例

ここで Human Context の例を見ていきましょう。ただの資料やデータベースとは何が違うのか。

Human Context とは、上述した「本来の意味でのコンテキスト」にあたるものです。同じ例を再載します:

  • 私個人のパーソナルな文脈
    • 信念や価値観など自分を形成するコアは何かしらあるはず
    • 中長期的なマイルストーンやスケジュール、直近のイベントなど計画も通常抱えているはず
  • 仕事に関する文脈
    • プロジェクト A、タスクフォース B、所属部門 C など所属や役割がある
  • 居場所ごとの文脈
    • 会社員としての私、日曜日の私、ゲーセンに遊びに来たときの私など、居場所ごとにキャラが違う

これらは一見すると仕事とは関係なさそうですし、AI に渡す意味もなさそうですが、案外そうでもありません。

  • 新製品を開発しているか、そのための実験をしているとしたら:
    • 製品のビジョンやコンセプトといったものは必要なはずです。AI は知らないですし、形式的なキックオフ資料や会社紹介資料だけでは足らないでしょう。きちんと言語化して、定義をして、他の考え方との比較や具体例を交えて、それを markdown に落として置くことで、ようやく使えるようになります
  • 個人で人生管理やタスク管理その他振り返りの仕組みを AI と行っているとしたら:
    • GTD でいう高度モデルのようなこと――つまり自身の制約や計画や信念もインプットしなければならないはずです。たとえばあなたはスローライフを目指しているのに、AI が競争的なプランやマイルストーンを出してきたとしたら、合わないですよね。ここを調整するには、あなた自身が「私はスローライフを志向している」と理解し、それを言語化した上で、AI に読ませる必要があります
  • 社内向けの報告を AI で端折りたいとしたら:
    • 通常、どの会社も独自の文化を形成しており、特に上位層ほど染まっています。組織が暗黙的に既定する何らかのルールやしきたり、もっと言えば言い回しや伝え方のニュアンス等があります。これらを踏まえない内容や様式は「無礼」であり、相手にされません。そんな様子を「AI は不正確だから……」「AI は責任を負わないから……」などと言い訳して正当化します。もちろん一理はあるのですが、それだけじゃ足りなくて、単に Human Context として自身の組織のあり方を反映できていないからです
    • たとえば「社内標準のパワポのテンプレートに見慣れている」せいで、事実上その様式以外はノイズが多くて受け付けづらくなっていることがあります。この場合、そのテンプレート（が表現する実際の様式）は Human Context と言えます
    • あるいはプレゼン先の上層部とその周囲が使っている語彙を使わないといけません。彼らが「バイブに行こう」と口うるさく言っているとしたら、Agentic Engineering というよりは Vibe Coding と表現するべきでしょう。また英語を使わないのだとしたらバイブ・コーディングが良いかもしれませんし、会社次第では「感覚コーディング」など独自用語がまかりとおっていることもあります
    • 官僚的な文化ですが、ステークホルダーとその力関係を一枚の絵で表現する文化があります。曼荼羅と揶揄されたりもしますが、文化ではあるので尊重しないと相手にされません。AI で曼荼羅をつくるのは無茶ですが、「登場人物とその力関係を一画面で表現できればいい」と抽象化したのなら、別のやり方ができるかもしれません

と、これらは一例にすぎませんが、どれも AI に何を与えるかの「何」にフォーカスしています。こういうのが Human Context なのです。こういったものを自分たちで言語化し、AI に与えられるよう整えるのが Human Context Engineering です。

言語化→構造化→概念化→道具化

Human Context Engineering の話を続けます。さて、Human Context Engineering では、コンテキストを次のように固めていけばいいと考えます。

  • 1: 言語化
  • 2: 構造化
  • 3: 概念化
  • 4: 道具化

以下、それぞれ詳しく見ていきます。

言語化

まずは 言語化 です。AI に与える「何」とは何なのか、のとっかかりを頑張ってつくる段階です。

これは非常に創造的かつ個人的なものであり、個人による深い集中と、そうして出された情報の読み込みの両方が必要と考えます。カジュアルにはブレストや KJ 法といった営み（の初期段階）がわかりやすいと思います。

※ちなみに AI エージェントの文脈だと、このあたりは「即興的に対話するスキルとして提供」がホットのように思います。例として Superpowers の brainstorming、oh-my-claudecode の deep-interview など。これらスキルを呼び出すだけで AI が色々聞いてくれて、言語化が捗るわけです

発散と収束でいうと発散の段階でもあります。発散というと、静的な情報源やそこに書かれた「誰かの言葉」を「そのまま」持ってくるケースが多いですが、それだと浅いです。Human Context の Human とはあなたのことであり、あなたのチームや組織のことです。自身の思うところや感じるところを言葉にしたいのです。

言葉でいうとかんたんですが、たぶん一番難しいと思います。自分の内面を外に出したり、自分の置かれた状況をメタに認知したりといったことが難しいからです。コンプレックスだったり、汚点だったり、目を背けてきた矛盾だったり、と普段一秒も相手にしたくないようなものとも対峙することになります。また言語化の対象は理想や妄想だけでなく現実も含みますし、むしろ現実がどうなっているかの言語化こそが大事なのですが、これも理想と現実のギャップを突きつけます。

たとえばイノベーションや探索には多様性が大事だと言いつつ、働き方は朝型しか許容してないよね、組織も管理職以降は急に10 割が既婚者になるよね、といった言語化をするわけですが、ここまで率直に切り込むのは難しい。自分の中で言語化するだけでも難しいし、これを外に出して他者に見せる・伝えるのはもっと難しい。

そういうわけで、言語化は、Human Context Engineering が最優先でカバーするべき部分だと考えています。かんたんに行えることでもなく（とはいえ慣れたらそんなに難しくない）、内省やメタ認知といったソフトスキル側の知見を多く使いますし、言語化を回す仕組みをつくるにはデジタルツールもたくさん使います。読み書きの営みもおそらく必須でしょうし、外に出せない表現を漂白するテクニックも避けられません。また私はロールプレイと呼んでいますが、ある種「演技」も使いたいですし、「匿名によるコミュニケーション」も使える余地があります――と、本記事ではこれ以上は割愛しますが、本一冊では収まらないほど広くて深い領域なのです。

構造化

次に 構造化 です。言語化の時点だと、言語化された言葉（単語だったりフレーズだったり文章だったり）が散らかっているだけですので、これを構造にします。

包含関係だったり、流れだったり、依存だったり、あるいは単に似てそうなものを固めるだけでも違います。本記事の、今見ている中見出しは「言語化→構造化→概念化→道具化」となっていますが、これも構造化ですね。私が「順番を書いた方がわかりやすい」「多すぎてもムズいので 4 つまで」と考えた上で、意図的にそうしています。また、小見出しとして「言語化」「構造化」など一つずつ区切っているのも同様に意図的です。4 つの流れを示した後、一つずつ詳細を見ていく構造ならわかりやすいはずだ、と思うです。

構造化により、いわゆる「つながった」感覚が得やすくなります。全体は部分の総和に勝るともいいますが、単に言語化された「部品」を集めるだけでは何も見えません。構造化とは、いわば全体の仮説を考えることであり、このおかげで部品の寄せ集めでは見えてこなかったことが色々見えてきます。もちろん言語化も促進されます。

ここで構造化というと、グループワーク的にみんなでやりがちですが、Human Context Engineering ではアンチパターンです。「設計と収束は少人数で行う」的な金言は知られていますが、構造化もここに位置します。もちろん、だからといって自分一人に閉じていては偏りすぎますし、他者にも通じません。ですので、各個人で構造をつくって、それを持ち寄ると考えます。

昨今はチームの時代であり、従来個人プレー的に作業していたエンジニアでさえも今はチームワークが必須ですが、一方でグループワークの圧が強いのも現状です。特に日本はエリン・メイヤーの言葉を借りると「階層主義かつ合意形成的」ですし、古くから「社会的手抜き」の概念もあります。そんなデバフがある状態で、構造化を行うのには無理があるのです。

文化レベルで染み付いてたこのあり方から脱し、各個人で構造をつくってそれを持ち寄るとの転換をするには？

この問いが重要なのです。Human Context Engineering としても、この転換に相当の紙面を割くことになるはずです。

概念化

それから 概念化 ですが、概念化とは「言葉を定義すること」と考えてください。

自分の頭の中にしかなくて他者に通じない観念とは違って、「概念」は第三者（AI 含む）に通じるものです。ただの用語定義ではなく、周辺の情報も整理して落とし込みます。エンジニアの方は ADR（Architecture Decision Records）のようなフォーマットを浮かべるとわかりやすいです。あのレベルで関連情報をちゃんと詰め込み、かつ言葉の定義も書いてあるようなものです。あるいは最近読んだユビキタス言語の記事もわかりやすくて、ドメイン駆動開発の概念ですが、ただの用語集ではないことを強調しています。

例として、私がつくった「実用的な概念」を展示したサイトがあるので、見てみてください → 知的生産に魅せられし者、stakiran/workhack2.0: 仕事術 2.0。また、本記事の Human Context Engineering や Human Context もまさに概念です。

概念化のメリットは言及できるようになること です。

たとえば「朝型や夜型といった体質があるのに、今の働き方は朝型を強要されるよね」という言語化があったとしても、このままでは言及はできません。少なくともしづらい。言及しづらいがゆえに、やりとりの効率が落ち、機会すらも落ちていきます。逆を言うと、言及しやすくなれば増やせます。私は「体内時計の多様性（クロノ・ダイバーシティ）」と概念化しました。朝型や夜型といった体内時計を多様性の対象とみなし、尊重しようとのニュアンスを感じ取れるでしょう。これにより、私たちはこの件について言及しやすくなり、議論や対話もしやすくなります。もちろん、定義その他中身はちゃんと書いておいて、読んでもらわないといけません。

もう一つ重要なのは 概念自体をメンテナンスしていける 点です。議論や対話を踏まえて、概念の中身を修正することで、より良い概念にしていけます。朝型と昼型の二値では足りなくてグラデーションで表現するべきだとか、グラデーションだと煩雑すぎるからシンプルにして、昼型も足して三択にすればバランスが良さそうだ、など「体内時計の多様性」という概念そのものを修正していけます。

この二つのメリットは 生成 AI を相手にする場合にも効きます。「体内時計の多様性」という言葉一つで通じるようになるのです。プログラミングでは関数やクラスやモジュールを作りますが、ここでいう概念化も似たようなもので、概念をつくることで使い回せるようになるのです。

ただし、常に概念をつくることが正解とも限りません。Human Context としても、朝型と夜型の尊重が本当に重要であれば「体内時計の多様性」など概念化すればいいですが、それほどでもないのなら言語化程度で十分です。この点も関数やクラスなどと同じですね。常に関数化やクラス化をするわけではない。

道具化

最後の段階が 道具化 で、これは文字通り道具として「使える」ようにすることです。

シャーペンや消しゴムのように物理的に使えるものもあれば、ソフトウェアのように電子的に使えるものもあります。あるいはテンプレート（記入する）やチェックリスト（項目を読んでチェックをつける）といった運用的なものもあります。

使いやすさとしては、一般的には次のとおりのはず。

物理的 > 電子的 > 運用的

しかし、この関係は逆転させたり差を縮めたりもできます。それこそエンジニアの皆さんなら、現実の物理的な道具を使うより、手元の PC でコマンドを叩いたりアプリを動かしたりする方が使いやすいかもしれません。そもそもスマホアプリは言うまでもなく身近です。

運用的な道具についても同じことで、テキストの扱いと解釈に慣れている者であれば、実はテンプレートやチェックリストは「使いやすい道具」だったりします。例として、私はシンプル化の問い というページを上げていますが、私であれば、これを 10 秒とかからず使い始めることができます。このページにアクセスして、コピーして、テキストエディタに切り替えて、貼り付けて、各行の下に回答を書き込んでいく――を素早く行えるからです。

※もっと早く使いたいなら、ローカルにテキストファイルで持っておいて、それを呼び出す方が早いです。こちらだと数秒以内すら可能になります。

なぜこのようなことを言っているかというと、比較的つくりやすい「運用的な道具」を使えるようになった方が有利 だからです。特に Human Context では文脈という概念的なものを扱いますので、物理的な道具や電子的な道具ではカバーできないことが多い。しかし、運用的な道具を机上で使うだけなら比較的可能ですし、もちろん道具を使ってはいるので、使わないよりは理解も捗ります。

先の「体内時計の多様性」についても、これを物理的な道具や電子的な道具にするのは難しいでしょうが、運用的な道具ならかんたんです。たとえば「あなたが朝型か夜型かを判定するチェックリスト」をつくればいい。この例だと「アプリで測れるじゃん」とか「精度の高いチェックリストを素人がつくるのは無理じゃない？」といったツッコミがあるでしょうが、例なのであしからず。実際は皆さんが自ら概念化した、おそらく「新しい概念」を道具化することになるわけで、運用的な道具が一番つくりやすいでしょ、という話です。

既存の理論や事例に接続する

Human Context Engineering の中身、特に私が考えていることをチラ見せしました。整備は今後進めていきたいです。

チラ見せはこの辺にして、最後に既存の理論や事例と接続したいと思います。

ジャーナリング

自分の思考、感情や出来事を書き出す習慣はジャーナリングと呼ばれます。自己啓発、特に自分と向き合う用途で使われると思いますが、エンジニアの皆さんも日記や作業ログをプレーンテキストに書くことがあり、知らずのうちに同等のことをしている可能性があります。

Human Context を言語化するには、個人の深い部分にまで潜る必要があります。そして深く潜るには、口頭の会話や普段の妄想想像その他考え事程度では不十分で、（よほどの才能を除けば）書きながら考えることが不可欠です。しかし現状、ジャーナリングは体系的に整備されていない。

ジャーナリングとは何でしょうか。ジャーナリングの本質は、他者に踏み込まれない聖域――完全にプライベートな空間で、自分に合ったやり方で書くこと です。これが意外と難しくて、たとえば「Slack の自分専用チャンネルにつぶやいていく」だとチャットの書き方から脱せないし、会社のツールなので個人的なことも書きにくい。分報のように他者に見えているものはもってのほかです。

しかし、アナログに手帳でペンで書けばいいかというと、タイピングに慣れた人にはつらいでしょう。そもそも「頭の中で豊富に整理できる人」と「書いたものを見ながら整理していく人」がいると思っていて、両者の手段は全く違います。自己啓発の世界では手帳術がもてはやされていますが、手帳でどうにかなるというのは「高速なタイピングができるからどうにかなる」と同じくらい、偏った立場にすぎません。アファンタジアという「頭の中にイメージを浮かべられない」特性もあったりします。

と、このように一筋縄にはいきません。そこで Human Context Engineering では、ジャーナリングのフレームワークを与えたいなと思っています。典型的にはジャーナリングにはこういう原理原則を踏まえるんだよ、全体の流れはこうなるんだよ、IT で自動化出来るのはこの辺で、AI で支援できるのはこの辺なんだよ、といった「鉄板」を整理するのです。

ジャーナリングは本当に人それぞれですので、事例を並べるだけでは刺さりません。ふーんで終わります。かといって、振り返りの手法は「チーム向けの」「ネクストアクションを出す」営みなのでジャーナリングとは前提が違いすぎます。もちろん、ジャーナリング・オタクのような人でもない限りは、進んで試すものでもないため「やってみて学ぶ」も難しい。原理原則も踏まえながら、腹落ちできるやり方を見つけてもらう形が良いでしょう。

工学として再現性があり、万人が使うことができて、かつ IT の力にも頼って楽できるような、何らかの体系をつくる段階に来ていると思います。体系だと重すぎるので、まずは実用しやすいフレームワークから始めたいですね。

フィードバックループ

長いので先に流れを書きます。

  • まず SECI モデルとダブルループ学習を紹介します
  • これらの本質は「実践によるフィードバックループ」にあり、Human Context Engineering でも取り入れたいです
  • しかし丸ごと取り入れると大きくなりすぎるので、実践の下準備までやる、との境界を引きます

では本文に入ります。

SECI モデルは「暗黙知」を語る上では避けては通れない重鎮です。S→E→C→I と流れていく（ループします）ので SECI と呼ばれます。暗黙知を言語化するところは E の段階であり、その後、C にて新しい知をつくったり、I にて実践を繰り返して身体化します。知識スパイラルと呼びますが、暗黙知の形式知化、形式知の整理、実践、そしてまた暗黙知を形式知化……と回していく営みまでカバーしています。

もう一つ、ダブルループ学習もあります。学習のレベルをシングルループとダブルループに区別しており、ダブルループは前提そのものを疑うループです。擬似コードで言えば、こんな感じだと思います:

while True:                          # 外側:ダブルループ
    前提を設定()
    while True:                      # 内側:シングルループ
        誤差 = 行動(前提) - 期待
        if 誤差 == 0:
            continue
        if 戦略レベルで対処可能:
            戦略を調整()
        else:
            break                    # 内側のループを抜けて前提を見直す
    前提を問い直す()

これらの理論から得られる示唆は、実践による検証も含めたフィードバックループを回すことです。

Human Context Engineering も例外ではなく、つくった Human Context は実際に実践します。実践は 3 つあると思っています:

  • 言語化・構造化・概念化したものを他者に読んでもらい、議論や対話をする
  • AI に食わせる形で整備した後、AI を動かして、結果がどう変わったかを考察する
  • 道具化したものを他者に使ってもらい、フィードバックをもらう

しかし、実践の仕方と道具化の仕方にまで踏み込むので行き過ぎですから、Human Context Engineering としては 実践を行うための準備をする（道具化は除く） まで扱いたいと考えています。

議論や対話をするために、あるいは AI に食わせて動かすために、何をどのように準備すればいいのでしょうか？

後者はすでに Agentic Engineering として今現在盛り上がっているのでどうとでもなりますが、前者はどうでしょう。対話にせよ、議論にせよ、どちらも現状は原始的かつコストが重く、エンジニアリングと呼べるほどの再現性と軽さはありません。ここは明確なボトルネックですので、Human Context Engineering で軽減したいです。

たとえば次のようなトピックを解決したい:

  • 対面、口頭、同期的コミュニケーションをいずれも使わずに対話をするには？また 100 人や 1000 人で対話するには？
  • 1 日 1 時間以上、Human Context の読み書きに時間を使うには？またそれを可能とするための、テキストを読み書きする手段とシステムの整備は？
  • 言語化した 1 万文字のテキストを、マネージャーや役員や顧客に読んでもらうには？

実際にこれらを実践するには社会的・政治的な諸々が必須ですし、Human Context Engineering では扱いませんが、それでも、その前段で、相当の準備をしておかないと「そもそも実践できない」わけです。上記はどれも古典的な対話の考え方からは思いつかない切り口だと思います。

つまり Human Context を検証するための切り口を用意する。できれば、切り口を運用に乗せられるだけの情報も揃えたいです。

単純な例として、「言語化した 1 万文字のテキスト」は生成 AI を使えば比較的楽に読めます。私は ブラックボックスな対話 と呼んでますが、中身を直接読むのではなく、中身が見えない前提で、AI との入出力によって理解を深めていくのです。まさに切り口です。

かんたんなことを小難しく言っているように聞こえますが、かんたんではない。少なくとも私はこれが出来る人を見たことがありません。古典的な対話や議論の考え方だと「1 万文字のテキストを読め」は論外となり、従来どおり 1on1 その他会議の形で会話することしかできません。当然ながら 1 万文字の濃い言語化が検証されることはない。生成 AI が使えるというのに、こんな原始的な部分でボトルネックになっているわけです。

もちろん、1 万文字のテキストを書く側の問題もあります。こんなものは 1 日 1000 文字書けば 10 日で仕上がりますし、本当に見せたくない部分の漂白を 3 日かけて行うとしても、2 週間でできます。しかし実際、ここまでできる人はほとんどいません。もちろんスキルやリテラシーも要りますが、それ以上に「このような書く営み」を動かすためのモデルが要るのです。古典的なモデルしか知らないと受け付けることができない。

読み手にせよ、書き手にせよ、受け付け可能にならないと始まりません。だから切り口を準備していきたいのです。新しい切り口により、新しいモデルがインストールされれば、検証の幅が広がります。古典的なやり方というボトルネックを脱して、検証の速度と質を上げられます。Human Context という「道具ではなく概念」がメインの世界だからこそ重要です。

ログベースのレビュー

GTD、バレットジャーナル、Agile Results のような人生管理メソッドが色々あります。これらの本質は日々やったことや考えたことの記録を残しつつ、定期的にその記録ベースで振り返りを行うことです。自己啓発的に言えばログ（記録）ベースの振り返り（レビュー）と言えます。

なぜこれが大事かというと、いきなり振り返りをして色々得ようとしても難しいからです。仮に月に一度、振り返りをするとして、その月にやったことや考えたことを思い出せるでしょうか。

ところが、毎日かんたんに記録しておいて、それを読み返すようにすると、やりやすくなります。私は DWMY Review と名付けて整理していますが、日単位で記録して週一で振り返り、週単位で記録して月一で振り返り、のように重ねていくと、だいぶやりやすくなります。

無論、これのするには毎日記録する営みが必要で、そのためには習慣、フォーマット、使うツールまでカスタマイズせねばなりません。かんたんに聞こえますが、実際の人口の少なさを見ると「思っている以上に難しい」です。

Human Context Engineering では言語化が重要であり、言語化には自分の内面を使います。そうでなくとも 日々やったことや考えたことはそれ自体があなたの「直近の文脈」であり、価値の源泉です。これを引き出しやすくするのに、ログベースのレビューが使えるのです。Human Context Engineering としてぜひとも取り入れたいトピックです。

クリエイティブ・シンキング

ブレインストーミングや KJ 法のようなアイデア出しの営みは、よく知られていると思います。Miro のようなデジタルホワイトボードなりアナログな付箋なりを使って、皆でアイデアを出し合って、その後ディスカッションして、最後に結論を――のようなワークはある種鉄板です。アジャイル開発では振り返りとして使われることも多いと思います。

この営みは、Human Context Engineering においても非常に重要です。Human Context は言語的な表現にすぎず、現実の曖昧で複雑なものすべてを表現することなどできません。かなりの部分を取捨選択、抽象化しなくてはなりません。複雑な状況を丁寧に構造化したり、関係者全員が端的に認知できる「わかりやすくて、でも雑でもない本質的な一言」を導いたり、あるいは 90% 以上を切り捨てないといけない状況でできるだけ納得感をもって進めたりすることになります。それを言語で表現するのです。

これは創造的な営みであり、創造に慣れた人つまりはクリエイターこそ少なくないでしょうが、体系化されてないのが実情です。実際、創造的思考（Creative Thinking）なる学問や体系やソフトスキルさえ、ろくに存在しません。研究や理論は多いのですが、実務に、たとえば工学のレベルには落とされていない。

「従来どおり、グループワーク的にやればいいんじゃないか」と思われるかもしれませんが、足りません。すでに体験されているかと思いますが、お互い遠慮しあって予定調和なものしか出ない（それさえも出ないこともある）か、我が衝突しあって荒れるかのいずれかです。学術的にも実践的にも、少人数で行うか個人で出し切ったものを持ち込んだ方が筋が良いのが現時点の合意と思います。しかし、その具体的な運用方法までは整備されていないし、現場では未だにオズボーンを源流としたグループワーク的営みに終始しています。まして現代は AI という最強の相棒が使えるのです。

Human Context Engineering では、AI に食わせるプレーンテキストで書くという前提で、創造的思考を整備したい。デジタルツールを多用するので、デジタルツールの流儀を知らなくてはなりません。加えて、本当に必要なのは、机と何時間も向き合って粘り強くひねり出す、みたいなソフトスキルだったりします。ひとりでこれを行い、チームでこれを行い、かつ守る仕組みが必要です。参考までに、以前私がつくった整理も置いておきます: soft-skills-engineering - クリエイティブ・シンキング。発散→収束→蒸留、ソロワーク原則、シールドとパージなどの原則を整理しています。

デザイン思考

ここでデザイン思考とは、現在使われているティム・ブラウンの仮説検証的なもの（共感→問題定義→アイデア創出→プロトタイプ→テストの 5 フェーズ）ではなく、ハーバート・サイモンの原典の方を指します。

サイモンはデザインを次のように定義しています:

現状をより好ましい状況に変えるための行動方針を考案する者は、誰もがデザインしている

また、その前段で人工物（the artificial）を「外的環境と内的環境をつなぐインターフェイス」と捉え直しています。

サイモンが言っているのは、建築や設計や作画といった表面的な営みではなく、あらゆるクリエイターが共通して行っている前段の部分です。それこそがデザインである、と。

Human Context Engineering も、まさにこの構図を持っています。人間が開発したり設計したり、人間と AI が協力してそうしたり、あるいは AI がそうしたりといったことではなくて、その前段です。かといって Window Context や Agent Context のような技術的な仕様の話でもない。本来の意味でのコンテキスト――私たち、人間自身が持つコンテキスト（Human Context）をつくることこそが重要であり、本質であり、ここを工学化して広げていきたいのです。

またインターフェイス論についても、次のように捉えることができます。

  • 内的環境 → Content
  • 外的環境 → Code（また Code が使われる現場・組織・社会も含む）
  • 両者をつなぐインターフェース → Context。動的なコンテキスト

つまり Human Context Engineering とは、Agentic Engineering にサイモンのデザイン論を持ち込んだものです。あるいは、AI 時代にデザイン思考（の本質）を取り入れたらこうなるよね、という提案です。

おわりに

Context Engineering には空白の地帯があります。それを Window、Agent、Human の 3 層で整理して、Human Context こそを追求していきたいと定めました。

Human Context Engineering と題して、その中身をチラ見せしました。コンテキストは動的なものである、言語化→構造化→概念化→道具化を経る、などの原則を据えて、筋の良いコンテキストを育てていくのだとしました。また、終盤では既存の理論や事例と接続することで妥当性を補強しました。

AI 時代の本質はコンテキストにあります。だからこその Context Engineering ですが、ここに Human Context Engineering を合流させることで、より盤石になると考えます。具体的な中身はチラ見せにとどまりましたが、IT に限らない、学際的な統合が求められます。もちろん今後整備も検証もしていかなくてはなりません。

工学として整備して、検証して……。ひとりかつ趣味では限界があるので、仕事にしたいところですが、ひとまず現時点の構想を本記事にてお出ししました。参考や刺激になりましたら幸いです。

GitHubで編集を提案

Discussion