ゴールシークプロンプトからAI社員へ —— 私の3年間は、全部つながっていた
プロンプト設計者から、AI社員が会社の仕事を進める業務OSの設計者になるまで。
3年前、僕のゴールシークプロンプトを見てくれた人へ。
「あのプロンプトを作っていた人は、いま何をしているんだろう」と思ったことがあるかもしれません。
今、僕はほとんどプロンプトを書いていません。
代わりに作っているのは、AIが会社の仕事を進めるための仕組みです。誰が何を任せるか。どの情報を見てよいか。どこで人に確認するか。実行したことを、あとからどう確かめるか。
プロンプト設計者から、AI社員と働く経営者へ。
こう書くと、大きな方向転換に見えるかもしれません。でも、自分の人生と3年間の開発記録を重ねて読み直すと、全部つながっていました。
物理学で、世界を「構造」として見ることを覚えた
僕は物理学を学びました。
複雑に見える現象でも、要素を分け、関係を見つけ、式として表せば扱える。目の前の出来事をそのまま受け取るのではなく、「この現象を生んでいる構造は何か」と考える訓練でした。
当時は、それがAIの仕事につながるとは思っていませんでした。
ただ、いま振り返ると、AIに仕事を任せる時も同じことをしています。曖昧な依頼をそのまま渡さず、目的、入力、制約、判断、出力へ分けていく。複雑さを消すのではなく、扱える構造へ変える。
最初の土台は、ここにありました。
工場で、仕事を「工程」に分けることを覚えた
次に働いたのは工場です。生産技術として、一人で複数の工程を扱いました。
仕事は、ただ並べれば終わるものではありません。
先に終わらせないと次へ進めない工程
同時に走らせられる工程
条件によって分かれる工程
基準を満たすまで繰り返す工程
順序、並列、条件、反復。
いまAI社員のSOPや依存関係を設計する時に使っている考え方は、工場で体に入ったものです。AIの仕事も、現場の工程と同じです。入口と出口だけ決めても動きません。途中のつながりと、止める条件が必要です。
Amazonで、人と仕事を動かすことを覚えた
Amazonでは、人のマネジメントを経験しました。
状況を理解する。計画する。人と時間を配分する。実行する。結果をまとめる。次の仕事へ学習を戻す。
マネージャーが毎日やっているこの循環は、いまAI社員を運用する時の循環とほとんど同じです。
違うのは、相手が人間かAIかではありません。
仕事を任せる側が、目的と責任をどこまで明確にできるかです。
2023年、すべてがゴールシークプロンプトとして形になった
2023年3月、ゴールシークプロンプトについての公開発信を始めました。
ゴールシークの中には、すでに現在のAI社員の原型がありました。
意図と目標を確認する
目標を実行可能な手順へ分解する
必要な変数を定義し、目標を捉え直す
一つずつ実行し、結果を記録する
エラーを観測データとして次の試行へ反映する
完了条件を確かめるまで仕事を保持する
やりたかったのは、うまい命令文を作ることではありません。欲しい結果を先に定め、その結果へ到達する構造をAIの中に作ることでした。
当時の記事は2023年3月だけで16本。関連するnoteは31本残っています。4月のプロンプト講座には723の「スキ」がつきました。Xにも当時の投稿が、現在のアカウント名義で残っています。
日付は正確に分けておきます。考え始めた時期と、確認できる公開記録の時期は同じとは限りません。この記事では、証拠の残る2023年3月を公開発信の起点として扱います。
3年間の開発記録が示していたこと
別にまとめた「AI駆動開発3年史」は、GitHub、note、Xに残った記録を実測したものです。
2023年のプロンプト設計から始まり、AIにコードを書かせるvibe-coding、Devinへの発注、Claude CodeとCodexの併用、Issue駆動開発、常駐エージェント、権限を中心にしたハーネス、複数のAIセッションを同時に統治する現在の体制まで、八つの時代がありました。
AIに任せる範囲が広がるたび、問題はプロンプトの外側へ移りました。
前回の判断を、次のセッションが覚えていない
AIごとに役割が曖昧で、同じ作業を重複する
間違った変更を、誰がどこで止めるのか分からない
「終わった」と言っても、本当に完了したか確かめられない
良い指示文だけでは、仕事は運用できません。
必要だったのは、手順、権限、記憶、人の判断点、実行記録でした。
3年史は「実際に何をしてきたか」を証明します。僕の人生は「なぜその道を進んだか」を説明します。二つを重ねると、現在のAI社員が突然生まれた商品ではないことが分かります。
プロンプトの中の構造が、Lark上の業務OSになった
現在は合同会社みやびを経営し、Lark上でAI社員が会社の仕事を進める業務OSを設計・運用しています。
ここでいうAI社員は、人間そっくりの万能AIではありません。
たとえば、会議が終わったあとの仕事を考えてみてください。議事録を読み、顧客情報を更新し、次のタスクを作り、フォロー文面を準備する。ただし、社外へ送る直前には人へ確認を返す。完了後には、何を実行したかを記録する。
2023年にはプロンプトの中にあった構造が、いまは会社の現実の中で動いています。
意図と目標を確認する → 依頼と完了条件を定義する
手順へ分解する → SOPと依存関係を作る
一つずつ実行する → 許可されたツールで仕事を進める
結果を記録する → 実行証跡を残す
エラーから学ぶ → 差し戻しと改善を次の実行へ戻す
完了まで保持する → 未完了の仕事を追跡する
変わったのはテーマではありません。
設計する範囲が、1本のプロンプトから会社の仕事全体へ広がったのです。
「瞬く景色の法則」という、自分のための言葉
このつながりを、僕は「瞬く景色の法則」と呼んでいます。
意図を問い直し、道筋を分解し、瞬きを重ねて世界を変える。
無限の瞬きの先に、理想は現実となる。
一回の瞬きは、考え、確かめ、実行する一回の試行です。
エラーが起きたら、失敗として捨てるのではなく観測データとして読む。世界の状態を少し更新し、次の瞬きを行う。その反復によって、最初の意図へ近づいていく。
僕はこの考えを、次の概念式でも表しています。
Ω(I, W) = ∫ E(I(τ), W(τ)) dτ
これは学術的に証明された自然法則ではありません。物理学、工場、Amazon、LLMとの時間がどう一つの設計思想へ合流したかを表す、僕自身の概念モデルです。
Ωは、僕にとって人生の積分です。
瞬く景色の法則とは、
— ハヤシシュンスケ｜合同会社みやび (@The_AGI_WAY) May 28, 2026
人間が自らの経験資本 Ω を用いて、
意図 I と世界 W を観測し、
思考 Θ・制約確認 C・実装 I の反復によって、
世界状態 W_n を理想状態 W_∞ へ近づける法則である。
3年間で、何を捨てたのか
捨てたものは三つあります。
一つ目は、「最強のプロンプトがあれば解決する」という考えです。プロンプトは重要ですが、それだけでは継続する仕事になりません。
二つ目は、「AIの数を増やせば生産性が上がる」という考えです。役割、権限、完了条件がなければ、人数ではなく混乱が増えます。
三つ目は、「作れたことが、求められている証拠になる」という考えです。3年間の開発記録は技術的な学習の証拠です。しかし、顧客需要や支払意思の証明ではありません。
だから今は、一つの会社、一つの繰り返し業務、一つの小さな検証から始めます。
あなたにも、あなたのΩがある
物理学を学んだ時、それがAIに使えるとは思っていませんでした。
工場で工程設計をしていた時、それがAIのSOPになるとは思っていませんでした。
Amazonで人を動かしていた時、それがAI社員を任せる訓練だとは思っていませんでした。
でも、人生の経験は消えません。新しい技術の前で、過去の経験は別の意味を持ち始めます。
3年前に、ゴールシークプロンプトを使ってくれた人へ。
あの時、プロンプトの中に書いていた「目標を確かめ、道筋を分け、実行し、記録し、完了まで進む」という構造を、僕はいま会社の中に作っています。
あの人はいま、プロンプトの続きを会社の中で作っています。
最後に、一つだけ教えてください。
あなたの会社で「AIに任せたいのに、まだ人が抱えている定型業務」は何ですか？
売り込みではなく、次に検証する一つの仕事を探しています。具体的な業務が浮かんだら、コメントかプロフィールの連絡先から教えてください。
#AI社員 #生成AI #プロンプトエンジニアリング #ゴールシークプロンプト #Lark #業務改善
プロンプトの続きを、AI社員としてどう実務へつなぐのか。個人で学ぶ、30日で試す、会社に導入する、の3つの入口をまとめました。
※会社側の実運用記録は法人note「はじめての方へ」で公開しています → https://note.com/miyabi_g_k
