大きなループの中に、小さなループがある——鬼速PDCAとループエンジニアリングをつなぐ構造

「でかいループの中に、ちっちゃいループがある」

配信で確認できること

2026年7月13日のAI経営術LIVEで、れんくんがショート動画制作の仕組みを見せてくれました。

バズっているテーマを調べる。台本を作る。評価役のAIがレビューする。音声、編集、投稿まで進める。投稿後は1時間、24時間、48時間、72時間とデータを取り、仮説が当たったかを検証する（14:36からの実演説明）。

一つの動画を作る工程の中に、調査、制作、評価、修正の小さな反復がいくつもあります。その一回分が、投稿後の実データを受け取る、もう少し大きな反復の中に入っている。

私はここで「ループエンジニアリングですね、まさに」と返しました（15:55からの該当箇所）。

続けて口にしたのが、今回の記事の起点になった言葉です。

「でかいループがあって、その中にちっちゃいループがあって、その中にちっちゃいループがあって」

そのあとに「フラクタル構造」と続けています（16:03からの該当箇所）。

さらに私は、AIが実行するにしても人間が実行するにしても、評価基準をどう決めるのか、なぜその点数が良いのか悪いのかを判断できなければ、改善のループにはならないと話しました。そこには知識だけでなく、実際にやってきた人の体験値が必要です（16:14からの該当箇所）。

れんくんも、小さなループのログが次の一周へ入り、小さなループと大きなループが一緒に成長していくと応じています（16:45からの該当箇所）。

私がここから受け取ったこと

この場面を見返したとき、頭に浮かんだのが鬼速PDCAでした。

PDCAとループエンジニアリングは、生まれた時代も、使われる道具も違います。それでも、全体の目標を見直す大きなループがあり、その内側で具体的な仕事を直す小さなループが回る。しかも、小さなループで得た事実が上のループへ戻る。

似ているのは、この骨格です。

『超鬼速PDCA』にも大・中・小のループがあった

気になってKindleの蔵書を調べると、冨田和成さんの『超鬼速PDCA』が入っていました。

第1章の図1-2「PDCAサイクルの階層」付近に、次の一節があります。

「私は上位で回っているものから大PDCA、中PDCA、小PDCAと呼んでいる。」

——冨田和成『超鬼速PDCA』第1章、図1-2「PDCAサイクルの階層」付近

図では、大PDCAの中に複数の中PDCAがあり、その中にさらに複数の小PDCAがあります。

たとえば、大PDCAが「事業を育てる」なら、中PDCAは「見込み客との接点を増やす」。小PDCAは「一本の記事の冒頭を変え、反応を確かめる」といった具体的な試行です。

これは、単に大きな仕事を小さなタスクへ分ける話ではありません。

それぞれの大きさに、目的、実行、観測、判断がある。

小PDCAの結果は中PDCAへ返り、中PDCAの結果は大PDCAへ返る。上位の目的が下位の判断基準を決め、下位で得た現実が上位の前提を書き換えます。

同じなのは「円」ではなく「入れ子」

PDCAは円で描かれるので、「一周したら、もう一周するもの」と理解されがちです。

しかし、鬼速PDCAとループエンジニアリングを重ねて見たとき、本当に大事なのは円ではありません。

大きなループ：そもそも何を実現したいのか
  └─ 中くらいのループ：どの課題を攻略するのか
       └─ 小さなループ：作る → 確かめる → 直す

小さなループは、目の前のズレを速く直します。

大きなループは、「その仕事を続けること自体が目的に合っているか」を見直します。

たとえば記事の導入を何度直しても反応が変わらないなら、文章ではなく、テーマや届ける相手が違うのかもしれない。そこで内側の修正を止め、中くらいの企画ループ、あるいは大きな事業ループへ戻ります。

だから、これは上から下へ命令するだけの階層ではありません。

目的は上から下へ流れ、現実は下から上へ返る。

この往復があるから、入れ子のループは一つの学習システムになります。

カルピス原液は、コンテキストエンジニアリングの源泉

ここで、同じ日の朝LIVEの話がつながります。

私は、2年分、900本を超える朝LIVEを、一冊の本へまとめる実験をしていました。話者ごとに分けた発言や公開物を蓄積し、AIが使える状態にしていく。その材料を、LIVEでは「カルピス原液は全部入っている感じ」と表現しています。

重要なのは、どのAIモデルを使うかより、自分が何を話し、何を考え、何を世に出してきたのかを一か所に残しておくことだとも話しました。

ただし、原液は濃ければ自動的に正しくなるわけではありません。その実験中にも、別人の名前が原稿へ混ざり、人間が気づいて取り除く場面がありました。さらに別のAIへ、設計や誤字のチェックもさせています。

この朝LIVEで話した親AI、子タスク、独立チェック、採点、基準を満たすまでの再試行は、すでにループの形をしていました。

ここでのカルピス原液は、流行語を足すための材料ではありません。

ループの中を流れる、自分の文脈と判断の源泉です。

原液がなければ、AIは毎回、薄い一般論から仕事を始めます。反対に、原液だけを大量に置いても、何を使い、どこまで任せ、どう確かめるかがなければ仕事にはなりません。

ここに、Context Engineering（コンテキストエンジニアリング）が入ります。

カルピス原液と、AIへ実際に渡すコンテキストは同じものではありません。

• カルピス原液は、発言、記事、実績、失敗、価値観、判定理由を蓄えた全体の貯蔵庫
• コンテキストは、その中から今回の目的に必要なものを選び、AIが判断できる形にした作業用の文脈
• コンテキストエンジニアリングは、何を選び、何を外し、どの順番と粒度で渡し、仕事の途中でどう更新するかを設計すること

プロンプトエンジニアリングが「どう頼むか」を主に扱うなら、コンテキストエンジニアリングは「その一周で、AIに何が見えているべきか」を扱います。

たとえば記事を書く一周なら、原液のすべてを入れるのではなく、次のような文脈を選びます。

1. 今回の目的と読者
2. テーマに関係する過去の発言
3. 採用した良い例と、却下した悪い例
4. 「なぜOKか」「なぜ違うか」という判定理由
5. 守る表現、避ける表現、最新の前提

[外部補足] 2026年7月18日確認 Anthropicの公式解説では、コンテキストエンジニアリングを、変化し続ける情報の中から限られたコンテキストウィンドウへ何を入れるかを選び、維持する営みとして整理しています。重要なのは、情報量を最大にすることではなく、望む結果に必要な高信号の情報を絞ることです。

カルピスの比喩で言えば、原液庫が大きいことは強みです。しかし、毎回すべての原液をコップへ注げば、濃すぎて飲めません。

今回の相手と目的に合わせて、どの原液を取り出し、どの濃さで、どの順番に渡すかを決める。これが、AI氣道でいうコンテキストエンジニアリングです。

そして一周した結果、新しい反応や人間の味見理由が原液庫へ戻る。次の一周では、選ばれる文脈そのものが良くなります。ここにも、小さなループと大きなループがあります。

ハーネスは、文脈を仕事に変える器

必要な文脈を選んだだけでは、AIはまだ安全に仕事を完遂できません。そこで必要になるのが、Harness（ハーネス）です。

ハーネスは、モデルの周りに置く実行環境です。目的、参照するファイル、記憶、スキル、使えるツール、権限、検証方法、失敗時の戻り方、停止条件をまとめて持たせます。

クルマにたとえるなら、AIモデルはエンジンです。エンジンだけでは、曲がることも、止まることも、安全に荷物を運ぶこともできません。ハーネスは、車体、ハンドル、ブレーキ、メーターを含む「仕事ができる状態」を作ります。

Addy Osmaniの整理でも、エージェントは「モデル＋ハーネス」、ループはそのハーネスを調査、実装、検証、再試行の反復で包んだものとして説明されています。

つまり、関係はこうです。

カルピス原液：発言・経験・判断を蓄えた全体
       ↓
コンテキストエンジニアリング：今回必要な文脈を選び、編み直す
       ↓
ハーネス：その文脈を使い、どこまで、どう仕事をするか
       ↓
ループ：結果を確かめ、次の一手を決め、もう一周する

原液、コンテキスト、ハーネス、ループは横並びの流行語ではありません。実装上は重なる部分もありますが、答える問いが違います。

原液から今回の文脈を作るのがコンテキストエンジニアリング。その文脈で仕事を実行できる環境がハーネス。その仕事が現実から学び続ける仕組みがループです。

ループエンジニアリングで、仕組みが自分を直し始める

ハーネスが一回の実行を支えるものだとすれば、ループエンジニアリングは、その実行を繰り返し可能な改善システムへ変える設計です。

一回ごとに人間が「次はこれをやって」と指示するのではなく、仕組みが仕事を見つけ、AIへ渡し、結果を検証し、状態を記録し、次に何をするか決める。Loop Engineeringの解説では、ハーネスの一段上に位置する仕組みとして整理されています。

ただし、ここで「AIが自分で反省する」とだけ考えると危険です。

作ったAIが自分で採点すると、都合よく合格を出すことがあります。生成役と検証役を分ける。合格条件を先に置く。最大試行回数を決める。証拠がなければ完了にしない。人間の判断が要るところでは止まる。

私が実際にやっている、Claude Codeに作らせ、Codexにレビューさせ、指摘を受けて直し、もう一度検証する流れも、内側のループです。

しかし、レビューを全部受け入れるだけでは、別のズレが生まれます。レビューとしては正しくても、最初の目的や、守るべき個性から外れる提案があるからです。

そこで必要になるのが外側のループです。

• そもそものゴールは何か
• 今回、変えてよいものと守るものは何か
• 何を証拠に完了とするか
• AI同士の判断が割れたら、どこで人間へ返すか
• 何回直しても改善しないとき、どの上位ループへ戻るか

内側のループが「正しく作れたか」を見るなら、外側のループは「そもそも正しいものを作っているか」を見ます。

Loopが増えたら、「関係」を見るGraphが要る

小さなLoopが一つなら、流れは追えます。

記事を書く。根拠を確かめる。直す。もう一度読む。

ところが、調査AI、執筆AI、検証AIが別々に動き、人間の承認も入ると、一つひとつのLoopが回っていても、全体がどこで止まっているのかわからなくなります。

• この仕事は、誰が担当しているのか
• どの親タスクから、なぜ委譲されたのか
• 終わった結果を、どこへ返すのか
• 何の検証を通れば完了なのか
• 人間の承認待ちで止まっているのか

これは、一つのLoopの改善速度ではなく、複数のLoopの関係の問題です。

[外部補足] 2026年7月18日確認 2026年7月17日、Peter SteinbergerさんはXで “Are we still talking loops or did we shift to graphs yet?” と問いかけました。「まだLoopの話なのか、それともGraphへ移ったのか」という挑発的な問いです。

私がこの問いから受け取ったのは、Loopを捨てろという意味ではありません。

Loopは、一つの仕事が時間の中で「作る、確かめる、直す」を繰り返す動き。Graphは、複数の仕事、AI、承認、検証がどうつながっているかを示す地図です。

技術的にも、OpenAI Agents SDKのRunnerは、モデル呼び出し、ツール実行、再実行、終了という一つのLoopを扱います。

一方、LangGraphのStateGraphは、状態を共有するノードとエッジで処理を結びます。Graphの中に分岐やLoopを置けますが、繰り返すなら終了条件が必要です。

Cockpitで実際にやったこと

この問いを、自分たちの仕事へ引き寄せて考えたのが、AGI Cockpitで動かした一つのタスクでした。

AGI Cockpitは、複数のAIへ仕事を渡し、進行、報告、承認、成果物を管理する作業ボードです。最初の依頼は、Peterさんの投稿が何を意味し、今後どうあるべきかを調べることでした。

調査の結果、外部のGraph管理サービスを新たに入れるのではなく、いま使っているCockpitのタスクボードを唯一の正本として、その関係をGraphとして読めるようにする方針を採りました。

そこでPhase 1として、既存のタスクとライフサイクル記録から、次の四種類のノードを読み取り専用で作る実装を行いました。

• work：何を実現する仕事なのか
• agent_lease：その仕事を担当する一時的なAIは誰か
• approval_gate：どの操作が人間の承認を待っているか
• verification：何の証拠が完了を裏づけるか

さらに、ノード同士を次の関係で結びます。

• 担当している
• 親から子へ委譲した
• 子から親へ報告する
• 承認待ちで止まっている
• 検証結果が仕事を裏づけている

たとえばブログ制作なら、概念上はこう見えます。

記事を完成させる仕事
  ├─ 担当する → 執筆AI
  ├─ 委譲する → 出典確認の仕事
  ├─ 裏づける → 記事検証の結果
  └─ 止めている → 人間の公開承認

これなら、「AIが作業中です」で終わらず、誰が何をしていて、何を証拠に終わり、いま何を待っているのかが見えます。

ただし、現在のPhase 1が行うのは、既存状態をGraphとして読み取るところまでです。タスクを勝手に増やしたり、担当を変更したり、公開を自動承認したりはしません。元のタスク状態も書き換えません。

内部タスクIDの3558c658は、この調査と実装を追跡するためにCockpitが付けた番号です。概念名でも、読者が覚えるべき用語でもありません。実装の出典をたどれるよう、記事末尾の記録にも残しています。

なぜ、これが入れ子ループの話につながるのか

Graphの各ノードの中では、AIや人間が小さなLoopを回します。調べるLoop、書くLoop、検証するLoopです。

その複数のLoopを、中くらいの企画や、大きな事業目的へつなぐのがGraphです。

大きな目的
  └─ Graph：仕事・担当・承認・証拠の関係
       ├─ 調査Loop：調べる → 確かめる → 更新する
       ├─ 制作Loop：作る → 読む → 直す
       └─ 検証Loop：試す → 判定する → 差し戻す

だから、LoopからGraphへ「乗り換える」のではありません。

一つひとつの仕事を育てるのがLoop。増えたLoopを目的へつなぎ、全体の詰まりを見えるようにするのがGraphです。

小さなLoop一つで足りるうちは、まずLoopだけでよい。調査、制作、検証、承認が並行し、関係を見失い始めたときにGraphを足す。この順番が自然です。

料理に例えると、Loopは味見、Graphは厨房の段取り

料理に例えると、この構造はぐっと見えやすくなります。

カレーを一鍋だけ作っている場面を想像してください。少し食べて、塩を足す。もう一度食べて、火を弱める。とろみを見て、水分を調整する。

作る → 味見する → 直す → もう一度味見する

これが、小さなLoopです。一つの鍋の中で、完成条件へ近づいていきます。

ところが、店の厨房ではカレーだけを作っているわけではありません。ご飯を炊く人、サラダを盛る人、アレルギーを確認する人、配膳する人が同時に動きます。カレーが完成しても、ご飯がまだなら出せません。アレルギー確認が終わっていなければ、盛り付けまで進んでも止めなければなりません。

そこで必要になるのが、注文票と厨房全体の段取りです。

「カレーセットを出す」という目的
  ├─ 調理担当 → カレーを作り、味見Loopを回す
  ├─ 炊飯担当 → ご飯の炊き上がりを確認する
  ├─ 盛付担当 → カレーとご飯が揃うまで待つ
  ├─ 確認担当 → アレルギー条件を照合する
  └─ 配膳担当 → 全条件が揃った皿だけを客席へ出す

この関係図がGraphです。Graphはカレーを煮込んでくれません。誰が何を担当し、どの仕事が何を待ち、何が揃えば次へ進めるかを見えるようにします。鍋の中ではLoopが回り、厨房全体ではGraphが仕事をつないでいるのです。

先ほどのCockpitのPhase 1も、この厨房の注文票に近いものです。料理を勝手に増やしたり、担当を入れ替えたりする自動料理長ではありません。既存の仕事、担当、承認待ち、検証結果を読み取り、「いま何が、何を待っているか」を見えるようにした段階です。

では、カルピス原液やコンテキストエンジニアリングは、料理のどこに当たるのでしょうか。

カルピス原液の比喩は、発言、経験、成功例、失敗例、判断理由が濃く蓄積されている状態を表しています。料理の比喩へ置き換えるなら、厨房の食材庫、過去のレシピ、味見記録、お客さんの反応がまとまっている状態です。

ただし、食材庫を丸ごと調理台へ載せても料理はできません。今日の一皿に必要な材料だけを選び、使う順番と分量を決め、傷んだ材料や関係のない材料を外す。この仕込みが、コンテキストエンジニアリングです。

そして、包丁、鍋、コンロ、タイマー、レシピ、衛生ルール、アレルギー確認、出してよい条件まで含めた厨房の実行環境がハーネスです。

整理すると、こうなります。

さらに大きなLoopでは、お客さんの反応、食べ残し、注文数を見て、来週のメニューや味の基準そのものを変えます。一皿の塩加減を直すLoopの外側に、一つの注文を完成させるLoopがあり、その外側に、店を育てるLoopがあるわけです。

料理の比喩で大切なのは、AIに全部の皿を自由に出させることではありません。どの味なら出してよいか、どのアレルギー条件では必ず止めるか、誰が最後の責任を持つかまで厨房に組み込むことです。

人間の味見にも、限界が来る

ここまで設計すると、次のボトルネックが見えてきます。

AIの内側ループは速くなります。記事、画像、動画、コードを作り、別のAIがレビューし、修正し、また出してくる。すると最後に、人間のところへ「味見してください」が大量に届きます。

人間が全部を見るなら、AIを増やすほど忙しくなる。

Addy Osmaniも、エージェントは人間がレビューできる以上の量を出せるようになり、希少になるのは人間の判断だと述べています。また、人間が内側の全工程に居続ける必要はなく、制約、サンプリング、監査、責任のループを持つべきだと整理しています。

これは「Human in the Loopを外す」という話ではありません。

人間を、すべての一周に立ち会う作業者から、どこを味見し、何を学習させ、どこで止めるかを決める設計者へ移す話です。

人間の味見を増やし続けるだけでは、外側のループが新しい抱え込み場所になります。かといって、味見をやめてAIの合格判定を信じ切れば、判断軸が薄まり、速いだけの仕組みになります。

だから必要なのは、味見をなくすことではなく、味見そのものを学習ループにすることです。

分身AIを育てることが、次の大きなループになる

ここで「分身AIひろくん」が必要になります。

最初は、人間が実物を見ます。

「これは私らしい」「これは整っているけれど違う」「この主張は根拠が足りない」「ここは粗くても熱を残したい」。その判定と理由を残します。

先ほどのOwn the Outer Loopでも、味見を仕組みにするには、判断に名前を付け、批評と具体例で練習し、その理由を明示することが勧められています。味見は、説明不能な感覚のまま抱えるのではなく、比較できる判断データへ変えられます。

分身AIは、その評価データから判断軸を学び、次から一次味見を担当します。

AIが作る
  ↓
別AIが事実・形式を検証する
  ↓
分身AIが「ひろくん基準」で一次味見する
  ↓
例外・高リスク・自信の低いものだけ人間へ上げる
  ↓
人間の判定理由を、分身AIとハーネスへ戻す

こうすれば、人間は全件を細かく確認しなくても、判断軸の更新から降りずに済みます。

もちろん、分身AIは人間の責任を引き取る存在ではありません。分身AIができるのは、過去の判断に照らして、選別し、指摘し、エスカレーションするところまでです。何を世に出すか、基準そのものをいつ変えるか、結果に誰が責任を持つかは、人間に残ります。

大切なのは、人間が味見を卒業しないことです。

ただし、毎回すべての皿を食べるのではない。代表例、境界例、失敗例を味見し、その理由を言葉にして、分身AIへ返す。

すると、次の入れ子ができます。

大きなループ：人間が価値観・責任・方向を更新する
  └─ 中くらいのループ：分身AIが判断軸を学び、一次味見を改善する
       └─ 小さなループ：生成AIが作る → 検証する → 直す

ここまで来ると、分身AIを育てることは、単なる自動化ではありません。

人間は、自分がなぜ良いと思ったのかを説明する必要が出てきます。暗黙の感覚が、比較、理由、例外、禁止条件へ変わる。その言語化によって、本人の判断軸も磨かれます。

分身AIを育てることは、自分の判断を外に出すこと。そして、外に出した判断を見直し、自分自身も育て直すことです。

これが、人間とAIが一緒に回す、もう一段大きなPDCAなのだと思います。

全体を一枚にすると、こうなる

この七つは、全部を一度に導入するためのチェックリストではありません。

原液がある。今回必要な文脈を選ぶ。ハーネスが実行できる形にする。ループが現実から学ぶ。ループが増えたらGraphで結ぶ。出力量が人間の味見を超えたら、分身AIへ判断を教える。そして人間は、評価軸そのものを見直す。

前の層で生まれた課題が、次の層を必要にします。

今日から作れる、最小の入れ子ループ

最初から大きなAI工場を作る必要はありません。

まず、繰り返している仕事を一つだけ選びます。ブログ記事なら、次の順番です。

1. 原液を一か所に置く 過去記事、発言、読者の反応、良い例、悪い例を集めます。

2. 外側の目的を一行で決める 「この記事で誰に、どんな変化を起こしたいか」を固定します。

3. 今回使う文脈を選ぶ 全部を渡さず、目的、読者、関連発言、判断例、守る条件だけを取り出します。

4. 内側のループを一つ作る 書く、根拠を確かめる、読み直す、直す、までを一周にします。

5. 証拠と停止条件を置く 何が確認できたら終わりか、何回で止めるか、いつ人間へ返すかを決めます。

6. 人間の味見理由を残す OK、やり直しだけでなく、「なぜ」を記録します。これが分身AIの教材になります。

7. ループが増えてからGraphを足す 担当、依存、承認、検証を見失い始めたときに地図を作ります。

8. 分身AIへ一次味見を移す 十分な判定例がたまった領域から任せ、人間はサンプル、例外、高リスクだけを見ます。

何度直しても良くならないときは、内側のループを速く回してはいけません。

「文章を直す」から「企画は合っているか」へ。「企画を直す」から「誰に何を届けたいのか」へ。一段上のループへ戻ることも、ループ設計の一部です。

まとめ

鬼速PDCAとループエンジニアリングが似ているのは、どちらも「回す」からではありません。

大きなループの中に小さなループがあり、同じ構造が違う大きさで繰り返されているからです。

小さなループが現実を観測し、その事実を上へ返す。大きなループが目的と基準を下へ渡す。この往復が、局所的な改善を全体の前進へ変えます。

その源泉になるのがカルピス原液。今回必要な文脈へ編み直すのがコンテキストエンジニアリング。実行可能な仕事へ変えるのがハーネス。改善を自走させるのがLoop。複数のLoopを結ぶのがGraphです。

そして、AIの出力が人間の味見量を超えたところから、分身AIの育成が始まります。

人間の仕事は、すべてを自分で確認することではありません。自分の判断軸を教え、例外を見つけ、基準そのものを更新し、結果の責任を持つことです。

分身AIを育てることで、自分も育つ。

その大きなループの中で、AIの小さなループを速く、深く、現実につながる形で回していく。これが、鬼速PDCAの先に見えてきたループエンジニアリングの実践形だと思います。

関連記事・CTA

• PDCAはもう古い？ Loop Engineeringを経営者の言葉で
• AIソロプレナーとは？「社長無人化計画」の本質
• 過去の自分に、今の自分を分析させる——Fableのセッション履歴プロンプト

AIを一人で抱え込まず、実践例を持ち寄りながら試したい方は、GPTs研究会にも参加してみてください。

元動画・参考リンク

主動画

• 動画名：【AI経営術LIVE】Fable5、GPT-5.6、Grok4.5より大切な本質とは？モデルが変わっても効くマーケティングの極意
• 配信日：2026年7月13日
• 長さ：36分57秒
• YouTube：動画を見る
• 本稿の起点：16:03からのフラクタル構造の話

関連する朝LIVE

• 動画名：2年分の朝LIVEを、AIで1冊の本にしてみる｜GPTs研究会朝LIVE2026年7月13日（月）朝7:00〜
• 動画ID：j0QsMsAiT8k
• 長さ：36分40秒
• 主な確認箇所：00:33（2年分のLIVEを一冊へ）、07:45（カルピス原液）、27:12（別人名の混入を人間が発見）、29:44（別AIでチェック）、31:04（採点と再試行のループ）

参考リンク・資料

• 冨田和成『超鬼速PDCA』第1章、図1-2「PDCAサイクルの階層」付近（Kindle版で本文を確認）
• Anthropic, Effective context engineering for AI agents
• Addy Osmani, Loop Engineering
• Addy Osmani, Own the Outer Loop
• Peter Steinberger, Are we still talking loops or did we shift to graphs yet?
• OpenAI, Running agents — OpenAI Agents SDK
• LangChain, Use the graph API — LangGraph
• AGI Cockpit, Operating Graph Phase 1 実装記録（内部task ID 3558c658、設計commit d3ff70c7、実装commit e6a83d6b）

※この記事は、2本のAI氣道LIVE、Kindle本文、実装記録、外部一次資料をもとにAI氣道のコンテンツエンジンで構成し、出典照合と品質チェックを行って公開しています。