AI駆動経営、始めました―AIエージェントを仲間に、1 人で始める経営OSの改革
この記事は「AI駆動経営」シリーズの第 1 回です。
はじめに
夏ですね。暑い日が続いておりますので、AI駆動経営はじめました。
クリエーションラインで VPoE をしている荒井ひろです。
AI活用による効率化や成果が内外で聞かれるようになって、しばらく経ちます。文書の要約、議事録の整理、資料のたたき台。たしかにどれも速くなりました。ただ、あるとき気づいてしまいました。仕事の形は、あまり変わっていないのです。
情報を集めるのは相変わらず人で、AI に貼り付けて聞くのも人で、返ってきた答えを仕事に戻すのも人。AI は道具としては優秀ですが、仕事の組み立てそのものは、AI が来る前のままでした。
この 7 月から、その逆をやる取り組みを始めました。AIエージェントが社内のデータに自分でアクセスして、気づきや提案のほうが先に出てくる。人はそれを見て判断する。 いまの仕事に AI を足すのではなく、AI がいる前提で仕事を組み直すとどうなるかを、経営のデータを使って検証しています。
タイトルの通り「始めました」の報告なので、この記事に華々しい成果は出てきません。代わりに、なぜやろうと思ったのか、どういう意思決定で始まったのかを書きます。
社内で AI活用を進めているものの効率化の域を出ていない、と感じている方に読んでもらえたら嬉しいです。
なぜやろうと思ったか
きっかけのひとつは、社内のあるプロジェクトで聞いた話です。現在はプロジェクト全体で 10 人を超える体制で開発しているのですが、人数が増えるにつれて、新しいことを始めるコストが上がっているというのです。このチームは、テックリードだけでなくメンバー全員が、要件にも開発の進め方にも主体性を持つ運営をしています。だからこそ、新しい取り組みを始めるには、まず全員で説明し合って納得をつくる必要があり、そのコミュニケーションコストが人数の分だけ膨らみます。少人数の頃なら翌日から試せたことが、いまは切り替えるだけでひと仕事になる。
同じことが、経営という単位でも起きていました。私たちの会社は、気がつけば 100 人規模になり、部門が分かれ、事業も 3 つあります。成長の結果であり、喜ばしいことです。ただ、会社が小さかった頃には一瞬で決まっていたことが、決まるまでに時間がかかるようになりました。誰も悪くないのに、遅くなるのです。 そしてこの遅さは、素早く動けることが強みのはずの、私たちのような規模の会社には致命的です。
世の中の変化は AI によってどんどん速くなるのに、組織の意思決定は規模とともに遅くなっていく。この差は、人の頑張りや会議の工夫だけでは埋まらないと思いました。人の営みの中で解決するのが難しいのなら、経営そのものに AI の力を持ち込む。変えるのは、情報の読み方と、意思決定の回し方の両方——いわば、経営のOSです。私たちはこれを「AI駆動経営」と呼んでいて、この記事のタイトルはそこから来ています。
もうひとつ、直接のきっかけは経営の見落としです。あとから振り返ると「なんで誰も気づかなかったんだ」という判断が、たまに残ります。誰かがサボったわけでも、ミスをしたわけでもないのに、です。
手を打っていなかったわけではありません。透明性を高めるためにダッシュボードを作り、KPI を置いて、1 か月と 3 か月のサイクルで検査してきました。それでも、目標と現実の乖離は毎年起きます。実績の検査はできているのに、目標と見通しの間のズレは、検査をすり抜けて次第に大きくなっていく。そして時間が経つほど打てる手は減っていき、気がつけば未達、という構図です。
理由は 2 つあると思っています。ひとつは手間です。実績と違って、見通しは一度作って終わりではなく、見通し続けなければ意味がありません。それを人だけでやるには、コストがかかりすぎます。もうひとつは視点です。見通しは、組織全体のバランスを完全に第三者の目で見る必要があります。どこかの事業の視点に寄った瞬間、希望的観測が含まれる見通しをつくりがちだからです。
一方で足元を見ると、データ自体は揃っているのです。売上の見通しは HubSpot に、工数とプロジェクト原価は TeamSpirit に、事業目標と KPI は Plane に、会計は freee に、毎日きちんと入力されています。足りないのはデータではなく、それらを横断して読み、見通し続ける「誰か」でした。
AIエージェントなら、これができるかもしれない。Claude Code のようなエージェントは、API 経由で複数のシステムからデータを取り出し、突き合わせて読むことができます。人と違って、飽きずに毎週でも見通しを引き直せますし、どの事業の出身でもありません。仮説としては、始めるのに十分でした。
効果を先に決めない、と決めた
やると決めて、最初に悩んだのは提案の書き方でした。社内で新しい取り組みを通すとき、普通は効果を書きます。何を、いつまでに、どれだけ改善するのか。書かないと通らない、とされている部分です。
今回はそこを書きませんでした。効果を先に定義しないと決めて、そのまま提案しました。
開き直りではなく、論理的にそうするしかなかったと思っています。AIエージェントが社内のデータを使って動く働き方を、私たちはまだ見たことがありません。見たことがないものの効果は、定義のしようがないのです。それでも無理に数値を置けば、必ず「いまの仕事の延長で測れる指標」を選ぶことになります。作業時間が何割減るか、資料作成が何時間短縮されるか。測れる的を先に置いた時点で、その的に当たる球を投げるようになります。 その瞬間、取り組みは効率化に着地して、仕事の形は変わらないまま終わります。
かといって、効果が見えるようになるまで待つこともできません。やらなければ、見ることもできないからです。効果が分からないから始められない、始めないから効果が分からない。この循環は、どこかで「分からないまま始める」を選ばないと切れません。
ただし「効果を約束しない」は「何も約束しない」ではありません。代わりに、進め方を約束しました。作り込まず、まずつないで動かす。データの正がどこにあるかを一箇所に決める。そして毎週、経営に報告しながら、やること自体を組み替えていく。成果や効果を曖昧なままにしておく代わりに、検査と軌道修正の頻度を上げて、進むべき道を誤らないようにする。このフィードバック構造は、スクラムから学びました。効果は約束できなくても、進め方なら約束できます。
どういう経緯で始まったか
この提案を、7 月に経営の会議に持ち込みました。「で、なにがどう変わるんですか？」に「まだ分かりません」と答える立場は、正直に言って説明が難しかったです。
承認は下りました。ただし、条件が 2 つ付きました。ひとつは、進める中で見つかる「現行のセキュリティガイドラインと、将来の実装が衝突しそうな点」を記録して、ガイドライン改定の材料として返すこと。ガイドラインの内側で使いながら、次の境界線を探す役割です。もうひとつは、活動を外部に発信すること。いま読んでいただいているこの連載は、その条件の実行でもあります。
体制は CEO 直下の 1 名、つまり私だけです。効果の分からないものへの投資として、これは筋が通っていると思います。小さく賭けて、毎週見て、続けるかどうかを判断できる形だからです。ちなみに 1 名という体制自体も実験です。AI が横にいる前提なら、チームは少人数化していくはずで、その前提が本当かどうかを、まず自分で確かめています。
理想を言えば、2〜3 人の体制で、学んだことを共有しながら進めたかったというのが本音です。ただ今回は、体制を確保する時間的にもリソース的にも余裕がなかったので、スピードを最優先して 1 人でのスタートを決めました。フェーズが進んだら、仲間が増えることを想定しています。
この「分からないまま始める」は、CEO 直下という体制の通り、CEO と私が一緒に決めたことでもあります。同じことを、CEO も X に書いています。
まだ検証の段階です。それでも、判断に使える材料はもう増えています。これまで気づけなかったことに、いくつか気づき始めています。
うまくいくかは、正直分かりません。進捗はまたここに書いていきます。
何をつないだか
構成は、拍子抜けするほどシンプルです。売上の見通しは HubSpot、工数とプロジェクト原価は TeamSpirit、事業目標と KPI は Plane、会計は freee。この 4 つの SaaS の API を読み取り専用でつなぎ、会議の文字起こしを足して、Claude Code から横断して読める状態にしました。
大事なのは、何も作っていないことです。やったのは、API をつないで、データを取り出して、突き合わせる指示を書くことだけ。重い部分はAIエージェントが引き受けています。従来なら、これは BI 導入プロジェクトとして起案して、要件定義をして、開発体制を確保する類の話でした。それが要らないので、投資判断の単位が「システム開発の予算」から「1 人の時間」に変わります。効果を先に約束できない取り組みでも、この大きさなら賭けられる。提案する側にとって、これはかなり大きな違いだと思います。
始めてみて、困っていること
順調な話ばかりではないので、困ったことも書きます。
ひとつは、データの「正」がどこにあるか問題です。同じ数字が、SaaS の中と、手元の Excel と、スプレッドシートの写しと、資料に貼った数字に散らばっています。人間は「たぶんこれが最新だろう」と勘で選べますが、AI は選べません。そして人間の勘も、しばしば外れます。正は SaaS のデータベースにあるものとして、あとは全部その写しだと整理しました。今後本格的に展開していく上でデータの「正」を保つための業務プロセスの変更も必要になってくると考えています。
それから、データが SaaS の中にあっても、AI が届くとは限らない問題です。一部のツールでは、人が画面を開けば最新の値が見えるのに、その値だけ API では取れません。いまは人手の運用でカバーしていますが、運用は忘れられます。実際、更新の止まった古い値を AI がそのまま読んでしまい、判断を誤る一因になったことがあります。データは存在するのに、AI がスムーズにアクセスできる場所にない。AI がいる前提で仕事を組むなら、ツールを選ぶ基準にも「人が見られるか」に加えて「AI が届くか」が入ってくるのだと思います。
最後は、AI に何を渡し、何をさせないかです。社内のデータに AI がアクセスする以上、リスクは実在します。ここは気合いでは防げないので、モデルの学習に利用されない API 経由でのみ使う、権限を読み取り専用に絞る、外部への書き込み経路を持たせない、といった仕組みの側で守っています。この設計の話は一本まるごと使いたいので、次回以降に書きます。
今のところ、見え始めていること
成果を語る段階ではないのですが、「やらなければ、見ることもできない」の「見る」が始まっている実感は、すでにあります。
たとえば、別々のツールに入っていた受注の見込みと社内の工数を初めて並べてみたら、前提の置き方ひとつで「人が余る」と「人が足りない」の答えが逆転することが分かりました。それぞれのツールの中では、誰も異常を見ていません。全員が、自分のツールの中で正しく仕事をしています。それでも、並べて初めて見える問いがある。ここには組織の分業そのものに根ざした、思っていたより深い構造がありました。この話も、連載の中で一本まるごと使って書くつもりです。
もうひとつ、意外なところで効いているのが「第三者であること」です。私がデータの裏付けのない見立てを口にすると、AIエージェントは「それはあなたの個人的な主観で、データの裏付けがありません」と平気で返してきます。組織のどこにも所属せず、誰の顔色も見ない読み手が、経営データの隣に座っている。先ほど「希望的観測が含まれる見通しをつくりがち」と書きましたが、それを最初に指摘されたのが、言い出しっぺの私自身だった、というわけです。
まとめ
見たことのない働き方の効果は、先に定義できません。だから効果ではなく、進め方を決めて始めました。やらなければ、見ることもできないからです。
もし自分の会社で同じ提案をするなら、必要なものは 3 つだと思います。効果を約束する代わりに、進め方（毎週見せて、組み替える）を約束すること。スコープと投資をできるだけ小さくすること。そして「うまくいくかは分からない」を、決裁する側と同じ言葉で共有しておくこと。うちの場合、3 つ目は CEO が X にも書いてくれる形になりました。
今後も「AI駆動経営」をテーマにこの活動から学んだことを書いていくつもりです。AI に何を渡し、何を渡さないと決めたかという安全設計の話。横断して初めて見えた、組織の構造の話。データの泥臭い落とし穴の話。書きたいことはすでに溜まっているので、次回も読んでいただけたら嬉しいです。
同じようなことを考えている方がいましたら、ぜひご意見を聞かせてください。
