こんにちは、AI に同じ説明を繰り返して「これ、前にもやったな」となりがちなアーキテクトのやまぱん！です 😅

補足コメントや質問、いいね、拡散、ぜひお願いします 🥺！
間違っていたら 優しく 教えてください！

TL;DR

AI を使うほど強くなる企業は、成果物だけでなく、そこへ至る人の判断、失敗例、評価条件を自社の知識として残し、次の実務へ戻しています。

Satya Nadella 氏は、企業が自ら構築・所有する AI 能力を token capital と表現し、人の知識や判断力である human capital とともに育つ learning loop の必要性を論じています。
原論考が見ているのは企業の内側だけではありません。産業固有の知識がコモディティ化され、経済価値が少数のモデルへ集中するのを避け、企業・産業・国へ価値が広く流れる frontier ecosystem を作ることまで論じています。
AI に成果物を一度作らせるだけでは、次の仕事はまたゼロからです。手順、判断基準、失敗例を instructions、Agent Skills、custom agents、コード、評価セットへ残すと、次回は前回の続きから始められます。
モデルの性能や提供元が変わっても、組織固有の手順と評価基準を自社側に残しておけば、学びを失いにくくし、同じ評価を再実行できます。
知識を貯めるときはアクセス権とデータ保護もセットです。Microsoft 365 Copilot は既存の Microsoft 365 のアクセス境界を使い、Microsoft Purview の秘密度ラベルと暗号化も考慮します。

本記事は 2026/07/17 時点の情報です。Satya Nadella 氏の論考 A frontier without an ecosystem is not stable が示す政治経済まで含めた構想を確認したうえで、その中にある human capital、token capital、learning loop を企業内でどう形にするかへ焦点を絞りました。

記事中の日本語での説明と実装例は私の解釈です。トークン資本 や 知の基盤 は Microsoft 製品の正式名称ではありません。

GitHub Copilot と Microsoft 365 は、原論考に登場する製品ではなく、私がこの考え方を企業内へ当てはめるために選んだ実装例です。GitHub Copilot の具体例は主に VS Code 上の機能を対象にしており、GitHub.com、Copilot CLI、Copilot cloud agent では、対応するカスタマイズ形式や配置場所が異なる場合があります。

同じプロンプトを、また打っていた

私は記事の調査、PowerPoint の作成、ブラウザー操作、コード修正などを AI に手伝ってもらっています。便利なのですが、しばらくはこんな使い方をしていました。

AI にやってほしいことを説明する
期待と違うところを直してもらう
うまくいった成果物を保存する
数日後、似た仕事で同じ説明をやり直す

成果物は増えます。ところが、AI に渡した判断基準や、途中で見つけた失敗パターンは会話の中に置き去りです。

たとえば記事を書くたびに「公式情報を優先して」「英数字と日本語の間には半角スペースを入れて」「公開前にリンクを確認して」と頼んでいるなら、毎回の入力は作業ではなく再説明になっています。

そこで、うまくいった会話を次のような形へ移すようになりました。

会話の中にあったもの	次回へ残す形	例
いつも守る規則	custom instructions	文体、コーディング規約、実行前後の確認
何度も使う作業手順	Agent Skills	調査、テスト、デプロイ、文書生成の手順
役割と使えるツール	custom agents	読み取り専用の調査役、実装役、レビュー役
同じ検証処理	コードやスクリプト	記事の frontmatter と表記を検証する処理
合格条件と失敗例	テストや非公開の評価セット（private evals）	出典 URL の有無、形式、禁止事項、期待結果

こうして残した判断基準や失敗例を、次回の入力に使えるようになりました。

この個人の工夫を、チームで再利用・評価・更新できる形へ広げると、企業が自ら育てる AI 能力につながります。

「トークン資本」は、トークンの消費量ではない

Satya Nadella 氏は論考の中で、企業が育てるものを human capital と token capital に分けています。

human capital: 人が持つ知識、判断力、人間関係、創意工夫、パターンを見抜く力
token capital: 企業が自ら構築し、所有する AI 能力

ここでいうトークン資本は、API トークンの残高や消費量ではありません。

二つの資本は、片方をもう片方へ置き換える関係ではありません。人が目的や文脈を与え、AI の出力を評価し、承認した判断を再利用できる形へ残す。その知識を使った次の結果から、人も新しいパターンや失敗を学び、判断基準を更新します。この往復が Learning Loop です。

人間関係、創意工夫、言葉にしにくい経験まで、すべてを instructions や評価セットへ変換できるわけではありません。人に残る知識と判断を human capital、そこから再利用可能にした AI の実行能力を token capital として、役割を分けたまま一緒に育てます。

二つの資本が一つのフォルダーへ一緒に貯まるわけではありません。この記事では、次のように分けて考えます。

資本	主に育つ場所	具体的に増えるもの
`human capital`	人とチーム	文脈を読む力、例外判断、関係者との信頼、結果からパターンを学ぶ力
`token capital`	組織が管理する AI の実行基盤	承認済みのルール、workflow、コード、評価ケース、入出力契約、監査方法

承認や却下の記録は、それだけで human capital になるわけではありません。人が記録を振り返って判断力を高め、再利用できる部分を手順や評価へ反映したとき、二つの資本をつなぐ材料になります。

本記事が原論考から取り出す問いは、この AI 能力を Learning Loop で育て、モデルを切り替えた後も組織固有の判断を再検証できるかどうかです。

この記事で扱うのは、業務ルール、承認済みの手順、評価ケース、入出力契約を自社で版管理し、実務で繰り返し評価・更新できる状態です。プロンプトや文書を保存しただけでは、ここには届きません。生成物やサービス内データの権利、保持、エクスポート条件は契約ごとに確認が必要です。

元論考が見ているのは、企業の外側まで

Nadella 氏の問題提起は、企業内の知識管理や AI アーキテクチャだけでは終わりません。少数のモデルが各産業の専門知識を取り込み、経済的な利益まで集中させれば、企業や従業員は、自分たちが育てた知識から得られる価値を手放すことになります。

原論考では、グローバル化の初期に起きた産業と雇用の空洞化を引き合いに出し、AI でも同じ構造を繰り返すことへの懸念が示されています。表面上の経済成長だけでは、知識、仕事、利益が一部へ偏ることで生じる影響を埋め合わせられません。ここでいう stable はシステムの可用性ではなく、その AI 経済が社会から受け入れられ、長く続けられるかという政治経済上の安定です。

そこで必要になるのが、最先端モデルだけを意味する frontier model ではなく、企業・産業・国が自ら Learning Loop を持ち、従業員の専門性も増幅される frontier ecosystem です。プラットフォームの内側だけで価値を回収せず、その上で活動する組織が自分の知識と AI 能力を育てられる状態を目指しています。

この記事では、この大きな構想のうち、一つの企業が Learning Loop と組織知を自社側へ残す方法を掘り下げます。以下の GitHub Copilot、Microsoft 365、Microsoft Purview は、そのための実装例です。

モデルが変わっても、会社の判断基準を失わない

AI を使うほど強くなる企業は、使うたびに自社の workflow、専門知識、判断、評価が厚くなる構造を持っています。

新しいモデルが出るたびに、ベンチマーク、料金、コンテキスト長、コーディング性能が話題になります。モデルの能力は重要ですし、私も用途に応じて切り替えます。

一方で、モデルの順位は入れ替わります。ある時点で最も良かったモデルを選んでも、その判断だけでは組織の知識は増えません。過去の会話に埋まった修正や判断を保存していなければ、次のモデルへまた最初から教え直します。

Satya Nadella 氏の論考では、企業にとっての機会は最良のモデルを選ぶことより、モデルの上に Learning Loop を構築し、人的資本とトークン資本を複利で育てることにあると論じています。

これは、入力データがモデルの学習に使われるかというセキュリティの話とは別です。サービス側が入力を基盤モデルのトレーニングへ使わなくても、自社が成果物だけを受け取り、試行錯誤を保存しなければ、自社側の学習は残りません。

AI が作った提案書を人が三度直して完成させた場合、完成版だけでは、最初の案の問題、人の判断基準、却下理由、品質条件が消えます。この修正過程を手順と評価へ変換すると、別のモデルでも同じ業務条件を確認できます。

Satya Nadella 氏の論考では、企業は一般的なモデルを交換するときにも、Learning Loop に組み込んだ「会社のベテラン」の知識を失わない状態を目指すべきであり、それがコントロールと主権のテストになると述べられています。

私は、このモデル交換可能性を API の差し替えだけでは作れないと考えています。同じ入力に対して何を合格とするか、その会社固有の評価セットが必要です。

たとえば技術記事なら、次のモデルでも同じ項目を確認します。

一次情報を取得できたか
主張と出典が対応しているか
社内情報や個人情報が混ざっていないか
Markdown lint を通過したか
読者が次に実行できる手順があるか

モデルが変わったときにこの評価を再実行できれば、単なるモデル比較ではなく、自社の仕事に耐えるかを確認できます。

評価セットが残っても、別製品への移行コストが自動的に下がるわけではありません。変換工数、再実装が必要な箇所、評価の不合格率を記録し、移行後も同じ業務条件を満たせるかを判断します。

「知の基盤」を 4 つの役割で分ける

Learning Loop を支える仕組みを、製品名ではなく四つの役割に分けます。

役割	自社側で正本にするもの	製品に依存する実装例	確認する問い
データとアクセス	原典、業務文書、公開区分、所有者、権限	SharePoint、OneDrive、Git リポジトリ	誰が何を参照できるか
再利用できる知識	判断基準、手順、失敗例、業務仕様、評価条件	instructions、Agent Skills、knowledge base	次の実行が前回の学びを読めるか
実行する仕組み	入出力契約、処理ロジック、承認点	custom agents、コード、API、CI/CD	知識を実際の仕事へ適用できるか
評価とフィードバック	合格条件、テストケース、レビュー記録	lint、非公開の評価セット、監査ログ	良くなったか、次に何を直すか

自社側の正本と、特定製品上の実装は同じではありません。業務ルールや合格条件は自社で管理できますが、.agent.md の形式、利用できるツール、モデルの能力、サービスの契約条件は製品に依存します。別環境へ移すときは変換と再評価が必要です。

人が実行結果を評価し、その判断を次の手順と評価条件へ反映する。この循環を、私は 知の基盤 と呼んでいます。

表の四つは、主に token capital を実務で動かす側の構成です。人は外から目標を与えるだけでなく、承認、例外判断、結果の評価を担い、そこで得た学びから次の基準を更新します。

Digital Feedback Loop との関係

この考え方は、Microsoft Learn の Digital Feedback Loop を AI との仕事へ広げたものとしても捉えられます。Digital Feedback Loop がデータを別のプロセス改善へ使うなら、Learning Loop では AI との試行錯誤、判断、修正結果を次の実行へ戻します。これは Microsoft の公式な対応付けではなく、私なりの整理です。

Microsoft Learn の図では、顧客、人、製品、業務から生まれるデータを AI と組み合わせ、別のプロセスや成果の改善へ戻す循環が描かれています。この記事の Learning Loop との関係を、次のように整理しました。

どちらも、結果を人や業務へ戻して終わりではありません。結果を見た人が判断基準を更新し、その変更を次の実行へ反映して循環させます。

出典となる Digital Feedback Loop の概念と元図は、Microsoft Learn の「ビジネスインテリジェンスを使用して情報に基づいた意思決定を行う」を参照してください。上図は元図の転載ではなく、本記事の説明用に私が構成し直したものです。

自分の業務で「最初の一周」を作る

私が最初の一周を作るなら、大きな AI 基盤を先に作らず、今週二度以上 AI に頼んだ仕事を一つだけ選びます。進め方は次のとおりです。

0. データ、権限、正本を確認する

会話履歴や失敗例には、顧客情報、個人情報、ソースコードが含まれることがあります。保存を始める前に、データの分類、保存先、閲覧者、保持期間、正本の所有者を決めます。

パスワード、API キー、トークン、接続文字列などの認証情報は知識資産として保存しません。記録へ残す前に削除またはマスキングし、誤って保存・共有した場合は対象を失効させてローテーションします。

1. 対象、期待結果、失敗例を固定する

対象とする仕事、入力の範囲、合格条件、既知の失敗、判定方法を先に固定します。「良い感じ」ではなく、重要な主張に一次情報がある、未確認事項を断定しない、既知の失敗を再発させない、といった観測可能な条件へ変えます。

2. 変更前の基準値を取る

固定した条件を使い、説明時間、修正回数、既知の失敗の再発率を記録します。仕組みを作った後だけ測っても、改善したか比較できません。

指標	測り方	品質を落とさないための条件
説明時間	セッション開始から、必要な前提を渡し終えるまでの分数	入力資料の準備時間は別に記録する
修正回数	人が不合格として差し戻した回数	合格条件を変更前後で固定する
既知の失敗の再発率	`既知の失敗が再発した実行数 ÷ 対象実行数`	失敗一覧と判定方法を先に固定する

この三つは中間指標です。企業では対象業務に応じて、リードタイム、不良率、監査指摘、顧客満足度などの結果指標まで追い、業務上の強さにつながったかを確認します。見る順序は、説明と手戻りの削減、品質と監査可能性の向上、業務のリードタイムや顧客成果への波及です。途中の指標だけが改善しても、最後の結果につながらなければ「企業が強くなった」とは判断しません。

対象となる仕事、入力の規模、使用モデル、測定期間も一緒に記録します。難易度が大きく違う仕事を単純平均せず、同じ条件のケースを比べます。

3. 再利用する形を選ぶ

残したいもの	選択肢	適用範囲と注意点
リポジトリ全体で守る規則	`.github/copilot-instructions.md`	リポジトリ固有の規約や検証方法
ファイル種類ごとの規則	`.github/instructions/*.instructions.md`	VS Code では frontmatter の `applyTo` で対象ファイルを指定。対応面は機能ごとに異なる
タスク固有の手順とリソース	Agent Skills	instructions、scripts、resources をまとめ、必要なときに読み込む
役割と使えるツール	custom agents	VS Code では `.agent.md` で instructions と利用可能な tools を定義
決定的に実行する処理	コード、スクリプト、workflow	実装とテストをリポジトリで管理
出力品質を判定する条件	単体テスト、lint、非公開の評価セット	業務上の期待結果をテストケース化

VS Code の公式ドキュメントでは、Agent Skills は instructions、scripts、resources をまとめた再利用可能な能力として説明されています。Agent Skills の基本は、以前の記事「🔥 はじめての Agent Skills 🔥 12 選＆リポジトリ一覧！ GitHub Copilot でも使える AI の手順書」でも紹介しています。

4. 次の実務で使い、同じ条件で測る

別の同種タスクで再利用し、変更前と同じ方法で説明時間、修正回数、失敗の再発を記録します。作成者以外にも試してもらえるなら、暗黙の前提が残っていないか確認できます。

トークン消費量も参考になりますが、少ないほど良いとは限りません。一度多くのトークンを使って再利用可能なコードや評価セットを作り、その後の実行コストと修正時間が下がる場合があるからです。作成時のコストと、繰り返し利用したときの総コストを分けて見ます。

ROI にはモデル利用料だけでなく、知識の抽出、レビュー、権限管理、評価の保守、教育、廃止判断に使う人件費も含めます。利用頻度が低い仕事や変更の激しい仕事では、資産化の維持費が再説明のコストを上回る可能性もあります。

再利用が進んだ後は、作成者以外の評価通過率や、モデル変更後の評価通過率も追加できます。修正回数を減らすためにレビューを浅くしないよう、合格条件は測定前に固定します。

5. 結果を正本へ戻す

正本を更新する前に、担当者とレビュー担当者が結果、例外、却下理由を振り返り、判断の根拠を共有します。この振り返りによって、人も新しいパターンを学び、次の判断基準を更新できます。

ここで人やチームに残る判断力が human capital の成長です。振り返りで見つかった不足は、その性質に合わせて戻し先を決めます。たとえば、規則なら instructions、繰り返す処理ならコード、合否の判断ならテストです。手順が曖昧なら Skill、ツールの権限が広すぎるなら custom agent を見直します。承認された変更が AI の実行条件へ反映されると、token capital も更新されます。

一回目で作成し、二回目で再利用し、結果を三回目の入力へ戻したところで、最初の Learning Loop が閉じます。

企業規模へ広げるときの 7 つの責務

四つの役割は、Learning Loop を説明するための概念モデルです。企業の業務を実際に動かす段階では、instructions や評価セットを保存するだけでは足りません。データの品質を保ち、業務システムへ安全に接続し、実行を止めたり前版へ戻したりできるところまで設計します。

企業実装で必要な責務	管理するもの	確認する問い
業務データとイベント	取引、文書、センサー、履歴の品質、来歴、鮮度、保持	AI が参照したデータは正しく、追跡できるか
業務システムとの接続	CRM、ERP、ITSM などの認証、参照・更新権限、API 契約、重複実行対策	AI は許可された操作だけを実行するか
知識と判断の資産	業務ルール、例外、失敗例、評価ケース、適用範囲、版	誰の判断を、どの業務で正として使うか
実行とオーケストレーション	モデルとツールの選択、状態、再試行、人の承認、停止、前版への復帰	失敗や例外が起きても安全に止められるか
評価と隔離環境	非公開の評価セット、本番へ影響させない再現・比較環境、リリース条件	変更後も品質と安全性の基準を満たすか
trace と監査	入力、参照知識、モデル・手順の版、tool call、承認、出力、業務結果	なぜその判断と操作になったかを後から説明できるか
ガバナンスと運用	所有者、変更承認、監視、コスト、SLA、事故対応、廃止	誰が運用し、いつ止め、何をもって投資効果と判断するか

Microsoft の企業向け AI アーキテクチャでも、統制されたデータ基盤、ID とポリシーを伴う業務システム接続、分離された開発環境、評価、trace、監視、中央ガバナンスが別々の責務として扱われています。特定製品を採用するかに関係なく、この分離は企業の token capital を運用可能な能力にするための確認軸になります。

企業規模の例: 仕入請求書の差異処理

架空の例として、複数拠点を持つ企業が仕入請求書の差異を処理する業務へ当てはめます。ここでは AI が支払いを自動確定するのではなく、根拠をそろえ、人の承認を受けて業務記録を更新するところまでを一つの Loop とします。

段階	業務で起きること	企業側へ残すもの
入力	請求書、発注、検収、契約条件、取引先マスターを集め、欠損や重複を確認する	データ品質の規則、来歴、正本、アクセス条件
実行	三点照合を行い、許容差内の候補と差異の理由を根拠付きで提示する	workflow、API 契約、使用したデータ・モデル・手順の版
人の判断	経理担当者が承認または却下し、高額案件や契約外の条件を上位承認へ送る	承認者、判断理由、例外、却下理由
評価	誤った承認、見逃し、不要な差し戻し、処理時間、根拠の完全性を業務結果と照合する	非公開の評価ケース、品質・リスク・業務 KPI
更新	単発の例外と再利用できる規則を分け、承認された変更だけを手順と評価へ反映する	feedback trace、変更履歴、新しい業務ルールと評価条件
次の実行	新版を限定範囲で試し、旧版と比較する。基準を下回れば停止して前版へ戻す	リリース判定、監視結果、停止条件、次の改善候補

この例で二つの資本に何が貯まるのかを分けると、次のようになります。

資本	この例で育つもの	次の請求書処理での使われ方
`human capital`	経理担当者が身に付ける、単発の事情と再利用できる規則を見分ける力、取引先や契約の文脈、例外判断	AI の候補を承認・却下し、未知の差異や高額案件を判断する
`token capital`	承認済みの許容差、例外条件、上位承認の基準、workflow、API 契約、評価ケース、停止条件	同じ条件を自動で照合し、根拠付きの候補を出し、既知の失敗を検査する

AI の候補と業務結果を見て、経理担当者は新しい差異のパターンを学びます。人が承認したうち、別の請求書にも適用できる判断だけをルールと評価ケースへ反映します。次の実行結果から人がまた学ぶ。この往復によって、human capital と token capital が一緒に育ちます。

この規模になると、token capital はファイルの集合ではありません。業務データ、実行基盤、人の決裁、評価、監査証跡がつながり、モデルや担当者が変わっても同じ業務条件で改善を続けられる能力です。

所有者、権限、停止条件を決める

個人が便利なプロンプトを持っている段階では、その人が休むと再現できません。チームで使うなら、用途、所有者、参照データ、合格条件、確認日、廃止条件を記録します。

Git リポジトリへ置いただけでは組織知になりません。資産ごとに業務責任者と技術管理者を決め、変更承認、定期確認、停止や前版へ戻す判断まで管理します。実務で使われなくなったものは更新または廃止します。業務責任者は判断基準と例外を承認し、技術管理者は実行する仕組みを保守します。利用者とレビュー担当者は結果や失敗を評価し、次に残す判断を一緒に決めます。

組織の知識を AI から検索しやすくすると、アクセス権が広すぎる文書も利用者が見つけやすくなります。私は、知識の蓄積とガバナンスを切り離せないと考えています。

Microsoft 365 側では、文書、メール、会議、アクセス権など、業務知識の参照と保護が中心になります。GitHub 側では、instructions、コード、テスト、workflow、変更レビューなど、実行可能な知識を管理しやすくなります。

両者を一つの置き場へ集約する必要はありません。業務手順の正式版は SharePoint、自動化するコードとテストは GitHub、実行結果と承認履歴は Issue や Pull Request に置く、といった分担が考えられます。

Microsoft 365 Copilot のデータ、プライバシー、セキュリティによると、Microsoft 365 Copilot は組織データについて、ユーザーが少なくとも表示権限を持つデータのみを表示します。また、プロンプト、応答、Microsoft Graph 経由でアクセスしたデータは、基盤 LLM のトレーニングには使われません。

Microsoft Purview による生成 AI アプリのデータ保護では、生成 AI が既存の過剰共有やデータ漏えいのリスクを増幅し得ること、秘密度ラベルや暗号化が、構成済みの対応データ経路で追加の保護層になることが説明されています。

ここで挙げた Microsoft 365 Copilot と Microsoft Purview の制御は、Microsoft 365 のデータと対応する AI アプリに対するものです。GitHub Copilot のリポジトリ、ローカルワークスペース、agent tools へ自動的に適用されるわけではありません。

GitHub Copilot 側では、リポジトリのアクセス権とレビュー手順を設計し、custom agent では使えるツールを絞ります。ファイルパスへのアクセスは、リポジトリ、ワークスペース、ツール、OS 側の権限と承認で管理します。

そのため、知の基盤を作るときは次を同時に進めます。

誰がどの情報へアクセスできるかを見直す
機密情報へ秘密度ラベルを付ける
AI の実行に与えるツールと権限を絞る
出力を人がレビューできる場所へ残す
修正結果を、権限を確認したうえで次の実行へ戻す

全部の文書を AI に読ませる ことが知の基盤ではありません。必要な人が、許可された知識と手順を使い、結果を検証できる状態を作ります。

うまく貯まらないパターン

作ったが、次の実務で使わない

instructions や評価セットを作っても、次の同種業務で再利用しなければ、説明時間や手戻りが減ったかを測れません。結果を正本へ戻せないため、Learning Loop も閉じません。

プロンプト集だけが増える

うまくいったプロンプトだけを残しても、前提データ、使えるツール、失敗時の扱いが変わると再現できません。繰り返す作業は、参照資料やテストまで一緒に管理します。

長い instructions へ全部入れる

常に読み込む instructions が大きくなると、そのタスクに不要な規則まで AI のコンテキストへ入ります。常時必要な短い規則、ファイル種類ごとの規則、必要なときだけ読む Skill を分けます。

成功例しか残さない

きれいな完成品だけでは、AI が途中で何を間違えたか分かりません。失敗例、却下理由、レビューで直した点まで残すと、次の評価条件になります。

以前の記事「Claude Code の Skills 記事を読んで、Gotchas から Agent Skill 設計を見直した話」では、一般論より、実際の作業で踏んだ Gotchas（落とし穴・ハマりどころ）を Skill へ戻す方が次の作業に効くと書きました。今回の話は、それを企業活動へ広げたものです。個人や特定のリポジトリで見つけた Gotchas を、業務の例外、却下理由、再発防止ルール、評価ケースとして組織で再利用できる形へ変えます。

失敗を経験し、人がパターンや見分け方を学ぶ部分は human capital です。その中から承認された学びを Gotchas、手順、テスト、評価ケース、workflow へ反映し、AI が次回から使える能力にした部分が token capital です。失敗のログを保存しただけでは、まだどちらの資本も十分には育っていません。

モデルの回答をそのまま組織知にする

生成結果には誤りがあり得ます。出典、レビュー担当、確認日、適用範囲を持たない文章を組織の正本にすると、誤りも複利で増えます。人が承認した内容と、AI の提案、未確認事項を分けて保存します。

まとめ

AI を使うほど強くなる企業は、成果物だけでなく、修正理由と合格条件を次回も使える形で残し、結果を人の判断へ戻す構造を持っています。

human capital にある判断を AI の実行条件へ残し、token capital を使った結果から人がまた学ぶ。私は、この往復が続く状態を Learning Loop と捉えています。

この記事では一周目の準備までできましたが、効果の確認はこれからです。次の記事で同じ手順を再利用し、説明時間、修正回数、既知の失敗の再発率を測り、結果をまた仕組みへ戻してみます。