経営会議は、会議室では行われていない

経営会議の半分以上は、もう会議室で行われていない。

少し前まで、会議の本体は会議室の中にあると信じていた。決まった時間に決まった場所に集まって議論し、決を採るその場にこそ会議がある。経営会議に限らず、会議とはそういうものだと思っていた。

経営会議に AI を入れていったとき、もちろん効率化は起きると思っていた。実際に起きたのは、それよりも一段大きい変化だった。決まる議題は、会議室に入る前にすでに決まりかけている。会議の場では、揃いきらない最後の差分だけが議論される。会議が終わった瞬間から、次の会議の準備が始まる。

これは効率化の話ではない。
会議のありかが、変わった話 だ。

困っていたのは、会議ではなく事前コメントだった

経営会議の運用には、重要なルールが一つあった。会議に入る前に、各議題に事前コメントを書く。「自分はどう思うか」「どこに論点があると考えるか」を、開始前にテキストで残す。会議の場で揃え直すのではなく、入る前に揃っている状態にしたい。そのための運用だった。

ところが、書こうとして、書けない議題があった。

議題そのものに、決まった型がなかった。

• 何を背景として、この議題は立っているのか

• 本当に解決したいことは何なのか

• この会議で何を決めるのか

これらを書く欄が、そもそも決まっていない。書かれている議題もあれば、タイトルと数行のメモだけの議題もある。埋まり方が人任せで、事前に考えようとしても、考える対象が定まらない。

結果として、事前コメントは機能していなかった。会議の冒頭15分が、毎回「そもそもこの議題、何の話でしたっけ」で溶けていく。会議の主役であるはずの意思決定は、そのあとの残った時間に追いやられる。意思決定のための時間ではなく、前提共有の時間に、会議の多くが消えていった。

困っていたのは、会議そのものではなかった。
会議に入る前の状態。事前コメントが、構造的に成立していなかった。

追いたかったのは、会議ではなく議題だった

事前コメントが書けない原因は、議題側に書くための型がなかったことだった。
では、なぜ議題に型がなかったのか。

掘っていくと、ドキュメント運用の構造に行き着いた。

当時の運用は Google Docs 中心だった。経営会議の議事録は、会議のたびに新しいドキュメントを作るのではなく、1つのドキュメントの上へ、上へと継ぎ足していく構造だった。中身はこんな構造をしていた。

2026-YY-YY 経営会議
- 議題C   ← 前回持ち越し
- 議題D
- 議題E

2026-XX-XX 経営会議
- 議題A
- 議題B
- 議題C

一見、何の問題もない。

ただし、ここに一つの運用上の癖があった。議論しきれなかった議題は、翌週の分に丸ごとコピー&ペーストして持ち越す。これが、毎週ふつうにやられていた。

毎週 10〜15 議題が上がる中、所定の時間枠で全部は決まらない。決まらなかった議題は、一番上に足された翌週の分にコピペされ、また同じように並ぶ。それでも決まらなければ、また翌週。先週の分からコピペされた議題が、また同じように並んでいる。3回、4回と連なる議題 がいくつもあった。

時間が経つにつれて、違和感が出てきた。

コピペされた瞬間、「前回なぜ決まらなかったか」も「次に何を決めるべきか」も切れる。コピーは前回の議論を継承しない。テキストだけが移動する。会議と会議が「同じ議題を持っている」のは事実だが、議題が会議の間を歩いて移動しているわけではない。新規の議題として再登場しているだけだった。

そこで気付いた。追いたかったのは会議ではなかった。

このライフサイクルを追いたいのに、ドキュメントは「会議」という単位でしか整理されていない。Google Docs は議事録ごとには綺麗に整うが、議題単位で見たいときに何もできない。ある議題が、いつ起案され、何回持ち越され、どこで決議に至ったか。それを追うには、半年分の記録を上へ上へとさかのぼって、コピペで連なる残骸を辿るしかなかった。

会議と会議の間は、つながっていなかった。
コピー&ペーストで、つながっているように見えていた だけだった。

問題の本質は二つだった

振り返ると、困っていたのはバラバラに見えて、根は二つだった。

一つ目は、事前コメントが成立しないこと。
議題側に型がない以上、事前に何を考えればよいかが定まらない。準備ができないのではなく、準備の対象が決まらない、という状態だった。

二つ目は、会議が孤立していること。
議事録は会議単位でしか整理されていない。前回何を決めたか、なぜそう決めたか、次に何を考えるべきかが、コピペでしか連結されていなかった。

この二つは独立した問題に見えるが、根は同じだった。
議題が、自分の場所を持っていなかった。

そして、これは誰のKPIにも乗らないコストだった。同じ議題が延々と循環しても、それは数字のどこにも現れない。会議の重さは、組織コストとして可視化されないまま蓄積していく。

会議中心の構造をやめる

会議中心の構造をやめた。

代わりに、議題 / 会議 / Next Action を別エンティティ として管理することにした。これまで議事録は「会議」を主語にして書かれていたが、それを「議題」を主語にした構造に作り直した。

ここで効いたのが、一つの見立てだった。会議は議題を入れる箱でしかない。これまでは、その箱ごと捨てて、中身を翌週の箱に詰め替えていた。中身（議題）に固有の場所を与えれば、箱を捨てても中身は残る。

• 議題 は議題として、自分のライフサイクルを持つ。複数回議論されようと、コピペされずに同じ実体として残る

• 会議 は議題を呼び出す箱になる。会議は議題を持つが、議題を所有しない

• Next Action は議題から派生する独立した実体。決定されたら、議題ではなく Next Action として走る

これだけでは足りない。議題そのものに型がなかったから、事前コメントが成立しなかった。だから議題側に構造を入れる。

議題に構造を入れたのは、最初から分類したかったからではない。むしろ逆だった。構造を入れて並べてみたら、偏りが見えた。その偏りに名前を付けた結果が、これから書く軸だった。

たとえば、3回4回と持ち越されていた議題には、共通点があった。それは「引く」議題。やめる・縮小する・撤退する種類の議題だった。一方で「足す」議題、つまり始める・追加する種類の議題は、たいてい一度で決まっていた。

同じ会議の中で、決まりやすい議題と、構造的に決まりにくい議題が混ざっていたのだ。

偏りが見えると、議題に複数の軸を立てたくなる。並べただけでは見えなかったものが、軸を立てると一気に可視化されるからだ。そうして導入した軸の中で、特に効いたのは次のものだった。

• 「足す」議題と「引く」議題を分ける軸：上の非対称性が、まず可視化される

• 「前提を問う議題」と「打ち手を決める議題」を分ける軸：同じ場で同じ時間枠で扱われていたものに、別々の名前を付けて呼べるようにする

• 「後戻りできる判断」と「後戻りできない判断」を分ける軸：前者は普段の意思決定で済むが、後者は議論の場と決裁レイヤーを変える必要がある

• 決定そのものに有効期限と見直しトリガーを持たせる：合宿で合意しても期限を切らないと実行されない、という過去の苦い経験から、「いつまで有効か」「何が起きたら見直すか」を決定のメタデータにした

これらは「議題を綺麗に書くため」の項目ではない。議論が滑り抜けがちな構造的な落とし穴に、名前と置き場を与えるための軸 だった。軸が立つと、事前に何を埋めるかが決まる。どこに視線を置くかが決まる。

つまり、議題を構造化したのは、事前コメントを「やる気」ではなく「フォーマットで」成立させる ためだった。

prepare / meeting / wrapup

議題を別エンティティにし、議題側に構造を持たせると、自然と会議のまわりに役割が立ち上がる。

会議は、もはや独立したイベントではない。継続する意思決定プロセスの一部 として機能するようになる。それぞれのフェーズに、別々の目的がある。

prepare の目的

prepare は、単に議題を読んでくる作業ではない。今回の会議で、何を、どこまで議論するか を整理する。議題の捌きそのものを含む。

• 今回扱う議題と、見送る議題を捌く

• 各議題について、どこから議論を始め、どこまで決めるかを定める

• 過去の議論を接続する（同じ議題が前回までにどう動いたか）

• 自分の仮説・スタンスを事前コメントとして残す

冒頭で困っていた「事前コメントが書けない」は、この prepare の中の最後の段階に過ぎなかった。書けない議題は、その手前 (捌きと議題の構造化)　が成立していなかったということだった。

これまで「会議の冒頭で前提共有から始まる」状態だったものを、会議の前に終わらせる。

meeting の目的

会議は、ほぼ揃った前提の上で、判断する場 になる。

• 揃いきらなかった最後の差分だけを揃える

• 残った論点を議論する

• 意思決定する

ここで起きるのは、情報共有ではない。
会議の価値は、情報共有ではない。判断にある。

wrapup の目的

会議が終わった瞬間が、終点ではない。次回への接続点 になる。

• なぜそう判断したか、判断理由を蒸留する

• 議論しきれなかった論点を、明示的に未解決として残す

• Next Action を生む

• 次回 prepare の起点にする

会議終了は議題の終わりではなく、議題の次フェーズの始まりだった。

AI Native 化とは、効率化ではない

「AI Native 化」と聞いて多くの人が想像するのは、会議中に AI を使うこと (議事録の要約、発言の文字起こし、その場の論点整理) あたりだと思う。

これは半分は当たっているが、本質ではない。

本質は、会議の前後が成立するようになったこと だった。

prepare は、人間の意志に依存していた

prepare には議題の捌き、過去議論の回収、自分のスタンス整理が含まれる。これらはすべて、人間の意志と時間に依存する作業だった。

• 過去に同じ議題が何回登場したか、何が決まり、何が宙に浮いたか

• 関連する論点、関連する未完了 Next Action

• 議題の構造化補助（背景・論点・選択肢の素案）

これらは「やった方がいいに決まっているが、毎週続けるのが難しい」種類の労働だった。AI が一番得意で、人間が一番続かない。

ここを引き受けるために、2つのスキルを作った。

• 起案スキル：議題に必要な構造（背景・論点・選択肢）の素案を AI が下書きし、起案者は事前コメントが書ける状態の議題に仕上げる

• prepareスキル：参加者全員の事前コメントを横断的に読み、「どこまで揃っているか」「どこから／どこまで議論すべきか」を AI が捌く

スキルを介すことで、prepare の成立コストが桁で下がった。これまで人がやれていなかった準備が、毎回行われるようになる。

wrapup も、放っておけば揮発する

wrapup も同じ性質を持っていた。会議直後に書き起こさないと急速に揮発する。揮発する前に蒸留して残す。会議後の疲労の中で人がやるには、最も流されやすい作業だった。

ここにも wrapupスキル を入れた。AI議事録から決定事項と Next Action を抽出し、各議題ページに決定事項として書き戻し、Next Action を独立した実体として登録するところまでを自動で走らせる。

スキルを介すことで、判断理由・論点・Next Action が、書き手の意志に頼らずに残るようになる。次回の prepare は、その蒸留物の上から始まる。

AIに引き受けさせることで、会議の重心が前に移る

prepare と wrapup が毎回成立するようになると、会議の重心が前に移る。

会議室に入る前にすでに決まりかけている。
会議室では差分だけ議論される。
会議室を出た後も、AI と人で蒸留が続く。

副次的な効果として、何件捌けたか・何件持ち越されたかも自動で記録されるようになる。会議そのものが、速度を持つ計測対象にもなる。

「効率化」と言いたければ、それも起きている。同じ議題が3回4回と循環することはなくなるし、会議の時間枠も自然と短くなる。だが、それは結果でしかない。

実際に起きたのは、会議の重心そのものが、会議室の外に移った ことだった。これは構造の変化だ。

AI Native 化の本質は、会議の中で AI を使うことではない。
会議の前後に AI が常駐し、会議の重心を前に動かしたこと だった。

判断の蒸留を、組織にスケールさせる

この構造は、前回書いた「AIに人格を移植してる」と言われるが、やっているのは真逆だったの「個人の判断の蒸留」と同じだった。

あの記事で扱ったのは、個人の判断だった。今回やったことは、その構造を組織に持ち込んだだけだ。

• prepare は、過去に蒸留した判断を呼び出す

• meeting は、新しい判断を作る

• wrapup は、その判断を蒸留する

やっていることは変わらない。スケールが、個人から組織に変わっただけ だった。

もうひとつ別の見方をすれば、経営会議には 組織が何を信じているかが出る。何を優先し、何を後回しにし、何を見なかったことにするのか。それらはすべて、組織の判断原則の表れだった。

思い返せば、延々と循環していたのは「引く」議題。やめる、縮小する、手放す判断だった。決められなかったのは、能力の問題でも、怠慢でもない。何を手放すかは、裏を返せば「何を手放さないか」を決めることで、それは組織が何を大事にしているのかを正面から問われる瞬間だった。だから重かったし、だから循環しつづけた。

プロセスを継続化するというのは、効率化の話に見えて、その実、この「何を大事にするか」を揮発させずに、毎回その場に引きずり出す作業でもあった。循環しつづけてきた問いが、もう逃げ場のない形で、毎回の会議に並ぶ。重かったはずのその問いが、可視化された瞬間に、むしろ前に進む推進力に変わっていく。

会議は、もうイベントではない

経営会議は、「イベント」から「プロセス」に変わった。

意思決定は、もはや会議室の中だけでは起きていない。会議に入る前と、会議が終わった後。つまり prepare と wrapup の時間の中で、議論の半分以上が動いている。会議室は、その流れの一断面に過ぎない。

AI Native 化は、会議室の中での効率化として始まったのではなかった。会議の前後と、会議の計測の中に AI が常駐することで、会議そのものが「単発のイベント」という形を失った。

もし、この構造を明日から自分のチームの定例で試すなら、入口は3つだけでいい。

1. 議事録の単位を「会議」から「議題」に変える：持ち越し議題を翌週にコピペするのをやめ、議題に固有のページを与える

2. prepare を会議の前に閉じる：冒頭の前提共有を、開始前のテキストに移す

3. wrapup を会議直後に蒸留する：判断理由と Next Action を、揮発する前に議題ページへ書き戻す

冒頭で、こう書いた。

書き出したときは、少し大げさかと思っていた。いまは、構造としてそう言える。

会議のありかは、もう会議室だけではない。

その先に、次のフェーズが見えてきた

prepare と wrapup が機能するようになった。
会議も接続されるようになった。
判断も、揮発せずに継承されるようになった。

そして、ここまで来て初めて見えるようになったものがある。

意思決定のプロセスが整い、判断が安定したぶん、これまで前提共有や持ち越しの混乱に紛れて見えなかったものが、剥き身で目の前に並ぶようになった。議題の中身そのもの。「問い」そのもの が、独立した対象として視界に入ってきた。

「どの議題を議論するか」ではなく、「なぜその議題を議論するのか」。

意思決定の階層を解決した結果、その上に乗っている 課題設定の階層 が、ようやく独立した対象として浮かび上がってきた。

意思決定の質を磨くフェーズは、ひと段落した。
ここから先は、問いの供給 という、次のフェーズに入る。

次回は「どう決めるか」ではなく「何を問うか」の話をしたい。