iwashi.co

意思決定で多数決ばかり使わないほうがよい理由と、おすすめの決め方

Mon, 06 Apr 2026 00:00:00 +0000

本記事は、1時間で読み終わるエンジニアリングマネジメント本を書き始めてみるで挙げたトピックの1つです。

はじめに

業務では、何らかの選択肢の中から1つを選ばないといけない場面が頻繁にあります。

エンジニアリングチームであれば、設計方針をどうするか、どの技術を採用するか、といった判断が日常的に発生します。プロダクトマネジメントでも、どの施策を続けるか、どの機能を優先するか、といった意思決定が必要になります。

そのときの決め方にはいくつかあります。リーダーが決めるのも1つですし、多数決で投票して決めるのも1つです。ほかにも、アジャイル界隈であればfist to fiveのような方法もあります。

このうち多数決は、比較的よく使われる選択肢の1つだと思います。選挙でも使われる方法なので、広く浸透しているのが強い理由の1つでしょう。

この多数決は、全員の意見を出すので一見公平に見えるかもしれません。ですが、実際にはそう単純ではありません。多数決にはデメリットが多くあります。代表的なものは、考慮されない意見の圧殺です。たとえば、文化祭の出し物を決める場合に多数決を使った場合、少数派の意見は切り捨てられるといったようにです。

個人的な意見では、多数決を意思決定のデフォルトの選択肢にしないほうが良い、というのが私の考えです。

多数決の問題

業務における多数決の問題は、少なくとも2つ大きな問題があると私は考えています。

最適解が選ばれるとは限らない

多数決は、「いちばん支持された案」を選ぶ仕組みであって、「いちばん良い案」を選ぶ仕組みではありません。

これが問題になりやすいのは、特にクリエイティブさや長期的な視点が必要な場面です。たとえば、選択肢のなかには、癖があるが独創的で長期的な価値をもたらすものがあります。ところが多数決では、こうした案が不利になりやすいです。理解しやすく、説明しやすく、無難な案が勝ちやすいからです。この辺りは、逆説のスタートアップ思考を読むと、よりイメージしやすいかもしれません。

いずれにせよ、平凡な意思決定に収束しやすくなります。短期的には納得感があるように見えても、最終的なアウトカムにつながりにくいのです。

やり方をミスると、ものすごく時間がかかる

もう1つの問題は、やり方を誤ると非常に遅くなることです。

多数決には、各人が内容を理解し（必要なら再説明して）、全員が投票して、結果をまとめる必要があります。人数が増えるほど、この一連のコストは急激に重くなります。

特に面倒なのは欠席している人がいて、投票が集まらない場合です。そうなると、意思決定が延期されてしまいます。

現代では、意思決定のスピード自体が競争優位の1つです。決まるのが遅ければ機会損失になります。逆に、すばやく決めてすばやく試せるなら、多少の粗さは後から修正できます。意思決定の速度を失うのは、かなりの痛手になります。

なお、多数決が向いている場面とコツもある

もちろん、多数決が全部悪いわけではありません。たとえば、飲み会の店、振り返りでちょっとしたネクストアクションを決めるなど、失敗しても影響が小さい場面では有効です。

また、多数決にもコツがあります。それはvote数を1つに決めないことです。では何個にしたらいいかというと、選択肢の半分ぐらいのvote数が良いでしょう。この辺りは、詳しくは『きめ方」の論理　──社会的決定理論への招待』を参照ください。

では、どうやって決めるのがいいのか？

個人的には、参加者の意見は取り入れつつ、誰か意思決定者を1人決めて、その人が決めてしまうのが良いと考えています。

理由は単純で、責任の所在が明確になり、決定が速くなり、文脈を踏まえた判断がしやすいからです。

意思決定は、単に票を数える作業ではありません。文脈を考慮し、選択肢のトレードオフを比較し、最後に組織としてどちらを取るかを決める作業です。ここでは、参加者全員の嗜好を均等に反映させることより、全体として良いアウトカムにつながるかどうかのほうが重要です。前述の通り、この方法であれば一定のスピード感を保ちやすく、試行錯誤もやりやすくなります。

実際の運用

実際には、以下のようなステップで意思決定するのが良いでしょう。

論点と選択肢を先に整理する
関係者から意見、懸念、前提条件を集めて、1に反映する
最終決定者が判断する、その際「なぜその案を選んだのか」をドキュメントに残しておく
周知する。必要に応じて、特に影響を受ける人には個別に説明する

この流れを事前に明確にしておくと、「全員の意見を聞いたのに、なぜ反映されないのか」という不満を減らしやすくなります。

大事なのは、全員の意見を全部採用することではありません。全員の意見を聞いたうえで、何を採用して、 何を捨てたか を明確にすることです。

採用されなかった意見への対処

もちろん、集めた意見の中には、最終案にまったく反映されないものもあります。

ですが、それをそのまま放置しないための手当てはできます。意思決定の記録として「こういう理由から、この案を選んだ」と残しておくことと良いでしょう。必要であれば個別に話をして、懸念点がどこで扱われたのかを説明すること。これだけでも、納得感はかなり違います。

全員の案を採用できないこと自体は、悪ではありませんし、そもそも現実的ではありません。問題になりやすいのは、議論が不透明で、なぜその案が選ばれたのかがわからないことです。

まとめ

多数決をデフォルトの選択肢にするのは、あまりおすすめしません。参加者の意見は広く取り入れつつ、最後は一人の意思決定者が決める。これが、速度と質の両方を保ちやすいやり方だと考えています。

AIに初手でたたき台を作らせない

Tue, 31 Mar 2026 00:00:00 +0000

生成AIをなんらかの叩き台の作成に使うという話や記事はいくらでも出てくる。だが、AIを使って初手から完全に叩き台を作らせない方が良い。この文章も、95% は手で書いている。

理由はアンカリング効果にある。簡単に言えば、最初に提示された情報が、その後の判断を強く縛ってしまう現象のことだ。

アンカリング効果では例えば、「トルコの人口は3500万人より多いか？」と尋ねられた後に具体的な人口を推定してもらうのと、「1億人より多いか？」と尋ねられた後に推定してもらうのでは、回答結果が大きく異なる。（なお、このパラグラフのみ、AIの力を借りて補強情報をまとめている。引用した例は HBR’s 10 Must Reads on Decision-Making, Updated and Expanded より）

転じて、AIに初手で叩き台を丸ごと作らせてしまうと、その情報がアンカーとなって人間の思考を強く引っ張る。初手からAIを使ったものは結果的に、自分の考えではなく、それっぽい情報を羅列したものになりやすくなる。何よりつまらないものが出来上がる。

もちろん、全行程でAIを全く使わないわけではない。大事なのは使うタイミングである。具体的にどうすべきかというと、任意の入力手段でまずは自分が言いたいことを箇条書きで書いてしまう方法が良い。自分の言いたいことが尽きるまで、箇条書きでもキーワードでもなんでも良いので、一旦出力してしまう。（音声入力が使えれば、一旦それで話し切ってしまうが個人的にはおすすめ）

おそらく、しばらく自分で文章を書いていないと、このプロセスがひどく苦痛に感じられるだろう。でも、その状態が正しいのだと思う。

このポストでまとめたように、「文章を書くことは筋トレと同じ」というのはまさにその通りだろう。筋トレを他人にやってもらっても意味がない。筋肉が自分についた状態こそ、思考の解像度が上がっている状態である。

叩き台を最初から作らせない。それだけで、体得できるものがだいぶ変わってくるはずだ。

「やめる」決断

Sat, 28 Feb 2026 00:00:00 +0000

本記事は、1時間で読み終わるエンジニアリングマネジメント本を書き始めてみるで挙げたトピックの1つです。

はじめに

新しい取り組みを始めるのは、簡単ではありません。取り組みを始めるためのリソースを調達する必要があるからです。

しかし、新しい取り組みよりもはるかに難しいのが、すでに続いているものをやめることです。個人的にはむしろ、始めるとき以上のコストがかかると感じています。改善施策であっても、プロダクト開発であっても、進んでしまっているものを止めるのは非常に困難です。

では、なぜやめる決断を下すのが難しいのでしょうか。

やめる決断が難しい理由

ステークホルダーの存在

着手してからある程度時間が経つと、PdM、営業、CS、運用など、複数のステークホルダーが自然と関わってきます。ちょっとした勉強会や情報共有の場であったとしても、チームや組織を横断していると、自然と関わる人が増えていきます。

そこでやめる決断を下すためには、（ものによりますが）関わる人全員に説明して合意を取る必要があります。「いや、やればいいじゃん」と思われるかもしれませんが、日々の多忙な業務の中で、この心理的なハードルと準備面のハードルを超えてやめる方向で動き出すのは、簡単ではありません。

特にプロダクトでリリースしているものがある場合は、顧客が関わってくるため、さらに難易度が上がります。顧客アナウンス、関連ドキュメントの更新、社内の調整、社内外の問い合わせ対応など、整理すべきことがたくさんあります。

サンクコストが重い

やめる判断が難しい理由のもう1つは、サンクコストです。すでに多大な時間やコストを投じてしまっているので、もったいないと感じてしまうのです。この兆候は会話の中で表出することがあります。「ここまでやったのだから」「せっかくだから」といった言葉が出てきた場合は要注意です。

すでに払ったコストは戻りません。やめるための判断時は「ここまで使ったコスト」ではなく、「ここから先の期間で、続ける場合の効果および他に費やした場合の効果」で考えたほうが良いです。いま継続して払っているコストは、将来の投資機会を逃し続けるコストでもあります。今やめて別のテーマに時間を使えば、新しい機会にチャレンジできるはずです。

やめる決断を下すためのポイント

やめる決断が難しいとはいえ、実現するためのポイントがいくつかあります。私個人が意識している、やめる決断を下すためのポイントを紹介しておきます。

始めるときに、終了条件まで決めておく

前回の記事でも書きましたが、何かを始めるタイミングで一番効くのは、最初から撤退ライン（終了ライン）を決めておくことです。

例えば、

どの指標がどこまで届かなければ止めるか
どの時点で判断するか
誰が最終判断するか

このあたりを決めておくと、「ラインに満たなかったのでここでやめる」と言いやすくなります。

とはいえ、実際には引き継いだ施策やプロジェクトもあるでしょう。その場合、こうしたラインが用意されていないことのほうが多いです。その場合は新規に期限を設けても良いでしょう。例えば、現状把握 → 2ヶ月後の目標値を設定 → 2ヶ月後に検証、そこで継続/縮小/終了の判断に持ち込む、という流れです。

「やめる」決断を下せるのは意思決定者だけ

基本的に決断しやすいのは、リーダーやマネージャーのように意思決定を担う立場の人です。逆に言うと、やめる判断は現場だけでは実現が困難です。

もし意思決定の役割を担っている場合は、「やめる」判断が長期的に大きな効果をもたらすことを意識しておいてください。自分にとっても簡単ではないかもしれませんが、チームメンバーは尚更難しいと感じているはずです。ちなみに書籍『みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた』では、組織重力の3法則として以下のように書かれています。

承認した最上位の人間が止めない限り動き出したプロジェクトは止まらない。

やめる決断をするときは、胃の中がキリキリするかもしれません。それでも長期的にみて正しい判断であることを信じて、勇気を持って決断しなければなりません。

やめるときは「結論」だけでなく「ストーリー」を語る

当然ながら「やめます」と話すだけだと、ステークホルダーや特に尽力してきたメンバーに納得感は生まれません。悪い知らせほど、背景の説明が必要です。

説明をする際は、できるだけ透明性を持って伝えることが重要です。例えば「戦略的見直し」といった抽象語で本音を誤魔化そうとしても、現場ではさっぱりわかりません。下手をすると不信感が募るだけになります。

それよりは、現状の診断、基本方針、次の行動をストーリーとして語ったほうが良いです。（なお、このスキーマは、書籍『良い戦略、悪い戦略』にあるものと同様です。戦略の話は別の記事で）

ストーリーを伝えるときは、少なくとも次の項目を押さえておくと納得感が高まります。

いま自分たちがどんな状況にあるのか
なぜ今やめる必要があるのか
組織としての大きな方向性は何か
この先何を目指すのか、どう行動するのか

伝える順番とタイミングを事前に設計する

やめる施策やプロジェクトの対象には、たいていキーマン、サブリーダー、関連部署のリーダー、現場メンバーなどが関わっています。ステークホルダーが多いほど、誰に・いつ頃・どの順番で話すかを意識しておくと良いです。これだけで着地の衝撃がだいぶ変わります。

順番を間違えると、意図しない形で話が先に伝わり、余計なハレーションが生まれます。そのため、「悪いことを伝えるためのコミュニケーション戦略」を先に設計しておくべきです。具体的には、簡易的ではありますが、次のように設計するイメージです。

キーマンに1on1で伝える、明後日までに実施
関連リーダーに説明して合意する（影響範囲、調整事項）、来週までに実施
実行メンバーに全体説明する + 問い合わせを個別に受けられるようにする、月末に実施
必要なら全社にも共有する（要点、問い合わせ窓口）、翌月初旬に実施

より詳細には書籍『レジリエントマネジメント』のChapter4が参考になります。

まとめ

始めるより、やめるほうが難しい。冒頭に述べたように、これは改善施策でもプロダクト開発でも同じです。やめる決断を下すために、

始めるときに終了条件を決めておく
引き継ぎ案件は期限付きを新たに設定して判断ポイントを設ける
サンクコストではなく、今後続けた場合とやめた場合の効果で判断する
最終的には、心理的ハードルを乗り越えて、意思決定者（リーダー）がやめる判断をする

を意識してみてください。わかっているけどサンクコストを払い続けている案件がないか、考えてみても良いかもしれません。

定例ミーティングのなくし方

Mon, 23 Feb 2026 00:00:00 +0000

本記事は、1時間で読み終わるエンジニアリングマネジメント本を書き始めてみるで挙げたトピックの1つです。

はじめに

この記事では、定例ミーティングが増える理由と、その定例ミーティングを減らす方法について書いていきます。

まず個人的な定例ミーティングの捉え方として、「定例ミーティングは必要悪」だと思っています。同期的に人の予定を抑えることから、コストが非常に高いのです。ただし、意思決定や腹落ち感の醸成などの効果も大きいためゼロにはできません。参加者の役割にももちろん依存しますが、基本的にはパフォーマンスを出すためには少なければ少ないほどいい。

マネージャーという立場で考えると、ミーティングはどうしても多くなりがちです。外部調整や部門横断の相談も多く、カレンダーはすぐに埋まっていきます。そうなると、予定調整そのものがだんだんパズル化してきます。この状況が、定例ミーティングを増やす方向に自然と働きます。

なぜ定例ミーティングが増えるのか

定例ミーティングが増える理由は、主に3つあります。

1つ目は、予定調整コストが高いことです。「誰がどこで空いているか」を毎回確認するのは、地味に大変です。実際、その都度調整しようとしても、全員の空き時間を見つけるのが難しく、結局「毎週この時間で固定しましょう」となりやすく増えていきます。

2つ目は、「念のため」の招待と情報共有の不安です。主催者側には「呼ばないと後で揉めるかもしれない」「情報共有の漏れを防ぎたい」という心理があり、本来は議事録共有で十分な人まで招待してしまうことがあります。参加者側にも「自分だけ取り残されるかもしれない（FOMO）」という不安や、「断ると角が立つ」という同調圧力があり、とりあえず出席が増えていきます。ちなみに参加者が増えた場合のミーティングでは、参加者が内職する可能性が上がるという結果もあります。(参考参照)

3つ目は、意思決定の責任分散と過度な合意形成です。誰か一人が決める責任を避けるために、「みんなで集まって決めた」という状態を作る目的で会議が設定されることがあります。加えて、事前根回しや全員の納得を重視しすぎると、情報伝達ではなく「顔合わせ」や「儀式」としての定例が増殖します。

つまり、定例は予定調整の合理性に加えて、組織心理の要因も重なって増えるわけです。

それでも、定例は増やしすぎないほうがいい

問題は、合理性を積み重ねた結果、カレンダーが定例だらけになることです。

本来やりたい仕事に使う時間、特に集中して考える時間が削られていきます。チームの生産性は、集中時間をどれだけ確保できるかでかなり左右されるので、定例ミーティングは冒頭に述べたように少ないほうが良いです。

では、どうやって減らすか。以下では個人的に効果があった方法を紹介します。

定例ミーティングをなくす方法

1. 最初から終了日を決める

定例を作るときは、できるだけ短い期間で取り、終了日時を必ず設定します。

例えば「このテーマは3か月で一区切り」と思うなら、3か月だけ定例を入れる。最初から1年やエンドレスで入れない。これだけで、かなりの会議が自然に整理されます。Google CalendarやOutlookの定例設定では、終了日を入れるのは簡単なので、新規に定例を作るときは、必ず入れるようにしましょう。

終了しても誰も困らないまま消える定例は、そもそも不要です。

2. 節目で定例をいったん全部消す

年末年始や期の変わり目など、区切りの良いタイミングで定例を一度すべて消す方法もあります。

必要な定例ミーティングは、結局また設定されます。逆に再設定されないものは、なくても回るということです。

「一度やめてみる」は、継続の惰性を断ち切るのに効きます。

なくしきれない場合のコスト削減

全部はなくせない前提でも、定例ミーティングのコストを下げる余地はあります。

1. 頻度を下げる

毎週開催しているなら、「本当に毎週必要か」を、ミーティングの終わり際にでも参加者同士で振り返ってみる手もあります。隔週に変えるだけでも、時間がかなり戻ってきます。5人参加で1時間の定例が隔週になれば、月間で10時間、年間120時間ほど集中する時間が増えます。

2. 参加人数を絞る

定例は、参加者を増やすのは簡単です。OutlookやGoogle Calendarでも、予定を転送すればすぐ増える。一方で減らすのは心理的に難しい。突然、参加者を削除したら「なんで？」となるかもしれません。

このときは、SlackやTeamsのチャットで次回以降の参加をオプトインにする方法が使えます。具体的には「参加したい人だけリアクションしてください」としておくと、自然と人数を絞り込めます。

まとめ

定例ミーティングが増えるのは、予定確保や調整コストだけでなく、情報共有の不安や責任分散の力学もあるからです。ただ、それを放置すると集中時間が失われます。

だからこそ、

定例には終了日時を入れる
節目でいったん全部やめる
頻度と参加人数を見直す

この3つあたりを意識するだけでも、一定の効果があります。というわけで、定例ミーティングの見直し、ぜひやってみてください。

参考：おすすめの書籍

ミーティング関係でおすすめの書籍がいくつかあるので紹介しておきます。

本文で言及していた、参加人数が増えると内職する人が増えるという結果も載っている書籍です。

amazon流でとても有名な、「会議冒頭で黙読する」を紹介されている書籍です。パワポやスライドを作るのが個人的に好きではないので、かなり参考にしています。

ミーティングというのは、ファシリテーターの振る舞いによって大きく成果が変わります。例えば、「今日は自由に話し合いましょう！」と投げかけても「シーン」となってしまうようなのは、ファシリテーターの振る舞いが不十分な例です。じゃあ、どうしたらいいかというのを、体系的に解説されている書籍です。

プログラミングは今が一番楽しい

Sun, 15 Feb 2026 00:00:00 +0000

AIコーディングの進化に伴い、特に2026年に入ってから、プログラミングに対する自分の見方がかなり変わってきました。現時点で考えていることを、いったん記録として残しておきます。あとで振り返ったら面白いと思うので。

なお、この記事はAIによる「てにをは修正」「タイポ修正」などの校正は入っていますが、内容そのものはすべて自分で書いています。

初めてのプログラミングは面白くなかった

Hello World を初めて書いたのは大学1年生のプログラミングの授業でした。SNSを見ていると「小学生から書いていました」という人も結構いますが、私はそういうタイプではありません。

大学の授業で最初に学んだ言語は Java。最初はマジでわからなかったです。そもそもプログラミング以前に、PATHを通すための環境変数の設定で詰まりました。MacとWindowsを両方使っていたこともあり、特にWindowsの設定画面 + DOS画面と格闘していた記憶があります。

この時期は「プログラミングが面白い」とはそこまで思えていませんでした。CLI上で for や if の分岐を書いて System.out.println() で出力するだけだと、あんまりテンションが上がらなかったためです。

プログラミングが面白くなる転機は研究室だった

転機になったのは大学3〜4年生の頃、研究室に所属してゼミのプロジェクトに携わり始めてからです。企業連携の取り組みがあり、プログラミングで現実世界につながる、誰かの役に立つものを作れる機会を得ました。

この頃から、プログラミングが一気に面白くなりました。プログラミングをはじめとして情報科学全般をもっと学びたいと思い、本気で勉強し始めました。CPUの仕組み、オペレーティングシステム、ネットワーク、データ構造とアルゴリズム、他にもGoF のデザインパターンを初めて学んだのもこの時期です。いま振り返ると、デザインパターンを使いたくて使う、みたいなひどい設計もかなりやっていました。卒論で書いた Chain of Responsibility は、間違いなく不要でした。

その後、大学院ではコンピュータネットワークの研究室に所属しました。研究領域はオーバーレイネットワークです。インターネット上で別のネットワークを組み、その上で最適なルーティングを行うような研究をしていました。この時一番書いていたのは C++ です。他にもちょっとしたスクリプトは Ruby で書いていました。C++はかなり大変でしたが、深夜まで悪戦苦闘して動いた瞬間はアドレナリンが出まくっていた記憶があります。

社会人5年目でもう一度コードにのめり込んだ

社会人になって最初は、いわゆるシステムエンジニア寄りの仕事だったので、オフィス系のドキュメントと向き合う時間が多かったです。プログラミングは本業では5%もなかったと思います。

ただ、思うところがあって5年ほど経ってからグループ内の別会社へ転籍し、ひたすらコードを書く仕事に移りました。ここが2回目の大きな転機でした。学生時代に感じた「プログラミングが楽しい」という感覚が、はっきり戻ってきました。

当時は会社の費用で技術書を買える制度もあり、技術書を読み漁っては、そこで得た知識を実装に応用する日々でした。気づけば、帰る時間が遅くなるくらい夢中で書いていました。

だいたいクラウドが浸透し始めた頃です。自身は WebRTCプラットフォーム開発をしていて、バックエンドやインフラを中心にクラウドを使って設計、構築していたのは本当に面白かったです。同時期に、（多分rebuild.fmで知った）ChefやAnsibleから冪等性という言葉に感銘を受けましたが、運用するにつれて現実の厳しさを知り、もう全部 disposable が一番だと思ったのもこの頃です。

DevOpsのチームに所属していたので、開発だけでなく運用にも携わっていました。この時は厄介なバグもたくさん経験しました。あまり詳細には書けませんが、たとえばグローバル分散環境でネットワークレイテンシーが絡む問題を解決できた瞬間は、いまでもよく覚えています。

その時の本番環境でしか再現してくれない不具合を切り分けながら潰していく過程は、しんどいけど最高でした。切り分けするにつれて原因がだんだん見えてきて、仮説を検証しながら修正して実際に動いた瞬間は最高なんです。

マネジメントに寄るほどコードは遠ざかった

その後、やりたいことが変わっていったこともあり、徐々にポジションが変わって、マネジメントに近い仕事へ移っていきました。その過程で私自身の興味の変遷もあって、一時期は人事も経験しています。そして直近では R&D のエンジニアマネージャーを担当していました（プライベートの事情もあり、2026年1月末まで。現在は休業中）。

エンジニアリングマネジメントの仕事に携わると、実際にコードを書く時間は激減します。業務で必要なら書くこと自体はできますが、チームや組織全体のパフォーマンスを最大化しようとすると、少なくとも私の場合は、どうしても実装以外に時間を使う比率が高くなりました。

ただし、プログラミングの時間が完全にゼロになったわけではありません。機械学習のちょっとした勉強や検証でPythonを書いていましたし、他にも大学の非常勤講師として PWA や Flutter を教える機会もあり、一定量は毎年書いていました。

この時のプログラミングも面白いと言えば面白いのですが、やっぱり本番環境に対して書いている時に比べるとちょっと物足りない感じはありました。プライベートで作りたいものもありましたが、家族との時間を優先するポリシーでまとまった時間も取れないので、タスクリストに積まれたままでした。

ただこの状況が変わり始めます。

Claude Codeから始まった進化の傾き

1年弱前、Claude Code を触り始めました。Claude Code以前のAIコーディング体験は、主に GitHub Copilot の「Tab で補完する」スタイルでした。それはそれで便利でしたが、Claude Codeを初めて触った時に「これは一線を超えたな」と感じました。

もちろん、かなり厳しいコードも出てくるので手直しも必要で、まだ人の関わる余地はかなりありそうだなと思っていました。

ただ2026年に入ってから、最新のLLMを使った Codex App や Claude Code、Antigravity を触るにつれて、さらにもう一段変わった感覚があります。もちろん、以前と同様にまだうまくいかないことも多いし、手直しが必要なこともあります。でも「ここまで書けるなら十分に使える」「これぐらいで十分では」と思える場面が明確に増えました。

この感覚が本記事のタイトルにつながっていきます。

結局、いまが一番楽しい

AIコーディングでの体験を重ねるにつれて、結局何が言いたいかというと、ものづくり、そしてプログラミングそのものが、いまはめちゃくちゃ楽しいということです。

思いついたものをすぐ形にできる感覚は、過去と比べても段違いです。以前は「何か作ろう」と思っても腰が重かったのですが、最近は「ちょっと作ってみるか」くらいの軽さで始められる。この変化はかなり大きいです。ライフステージが変わるにつれて、まとまった時間を取りにくくなる中では特にそう感じます。

もう1つ楽しくなった要因は、様々なものの学習ハードルが劇的に下がっていることです。難解な技術や概念にぶつかっても、今は LLM と議論すれば、かなり短時間で理解の足場が作れます。また、NotebookLM のようなツールもあり、プライベートの片手間にマルチモーダルでの学習もできるようになっています。これも、学習のハードルを大きく下げてくれています。

プログラミングを始めてから20年以上経つわけですが、プログラミングそのものが一番楽しいのは現在になりました。バグと悪戦格闘する時間は確かに減っていますが、実際に何かを作って物が動いた瞬間をすぐに体験できるのは、やっぱり最高です。

これから確実に変わること

約1年前、ティム・オライリーが The End of Programming as We Know It を書きました。オライリー氏の記事を（恣意的ですが）ざっくりまとめると、以下のようなポイントになると思います。

プログラミングの「終わり」ではなく、かつてアセンブリから高級言語へ移行したのと同様に、AIという新たな抽象化レイヤーによる「進化」である
AIがコード記述（How）を支援することで、人間は解決すべき課題や設計（What）により集中できるようになり、開発の民主化と生産性向上が加速する
過去の技術転換と同様、この変化は開発者の職を奪うものではなく、AIを使いこなすことで新たな機会やより高度な役割を創出する

AIによってソフトウェアエンジニアの作業が減るという記事もよく見ますが、以前と同じような役割のエンジニアの仕事が減るだけであって、AIコーディングのオーケストレーションエンジニアといったような役割がどんどん増えていくんだと思います。

また、組織設計もかなり変わるはずです。これまで主流だった2pizzaチームの形も、AIネイティブな前提で再定義されると思います。従来のプロダクトトリオ（PM、デザイナー、エンジニア）の分担も確実に変わるでしょう。

マネージャーにとってもかなり面白い時代です。少人数でAIを前提にプロダクトを作るチームは、スタートアップだけでなく大企業でも増えていきます。現状の組織は、おそらく従来型の構成やプロセスで動いているはずです。今後は将来からバックキャストして、AIネイティブな組織・プロセスづくりを積極的に先導していく動きが必要になり、マネージャーが大きな役割を果たすことになると思います。もちろん役割の中には、変わるものもあれば、変わらないものもあるでしょう。前回の記事は、それでも変わらないものがあると考えて記しています。

何もわからん

これまで私は、ソースコードレビューやステークホルダー説明をはじめとした人間の役割は長く残るだろうと思っていました。一定は今後も変わらない部分はあると思います。人間の信頼貯金は偉大です。

ただ最近は思ったより早く変わっていくだろうなと思っています。たとえば、レビューそのものも専用エージェントの精度が上がっていき、実用上かなりの範囲を担えるようになるのではないか、と感じるようになりました。そもそも人間のレビューにも見落としや設計上の抜けは当然ありますし、人間は完璧ではありません。高性能なLLMがこの領域を大きく置き換える可能性は十分あると思っています。

ちなみにOpenAIでは「OpenAIのエンジニアの95%がCodexを使用しており、すべてのコード変更はAIによってレビューされるという徹底した活用が行われている」（95% of engineers use Codex. 100% of our PRs are reviewed by Codex）だそうです。

もう1つ、最近のプロダクト開発では「今できること」だけを前提にしないほうがいいと感じています。半年後、1年後にAIがどこまで進化するかを見込んで設計する。その視点が、実際の戦略に入ってきています。

などといろいろ書いてきましたが、この1年の界隈の進化速度を見ていると、10年後は本当に何もわからんなと思います。

現時点で、「AIはまだまだ」「人間のほうが良いコードを書ける」という声があるのも事実です。私もその指摘自体は理解できます。ただ同時にクラウドがおもちゃ扱いされていた頃を思い出します。前提は想像以上に速く更新される。現時点の限界よりも、半年後・1年後に何が可能になるかを想像して課題設定、および意思決定したほうがよいと考えています。

あともう1つ、「最終的に責任を取るのは人間」という話もよく出ます。説明責任の観点から見れば、その通りだと思います。ただ、それがどこまで、どの形で続くかは正直まだわかりません。AIが作った説明の方が真っ当だな、と思うこともあるからです。「ハルシネーションがーーー」という声もありますが、人間もハルシネーションをたくさん生み出しています。

最後に

約20年前、Java の環境変数で詰まっていた頃の自分に、「2026年には、こんな速度で作れる時代になる」と言っても、たぶんまったくピンと来なかったと思います。

でも、実際にいまはそうなりつつある。良くも悪くも変曲点に立ち会えているのは、すごく面白いことだと思います。さて、来年の今頃に記事を読み直したら、自分がどんな感想を持つのか、楽しみです。

1時間で読み終わるエンジニアリングマネジメント本を書き始めてみる

Sat, 14 Feb 2026 00:00:00 +0000

はじめに

これまで、エンジニアリングマネジメントに関する本を何冊か翻訳してきました。どれも学びが多く、実践につながる内容です。

一方で、翻訳しながらずっと感じていたこともあります。

日本の現場にはそのまま当てはめにくい
理解はできるけれど、個人的にはあまり共感できず採用しづらい
要点は有用。だが、そこに至るまでがやや冗長で、時間がないマネージャーは読み切りにくい

私自身のN=1ではありますが、共感した部分や実践して有用だった部分を軸にして、もっと手早く読める形でまとめたいと思いました。自分自身がすべてできているわけではありませんが、そこは棚に上げつつ、こうするとうまくいく、あるいはうまくいったものを現時点でのスナップショットとして残しておきたいと思っています。

本書で作りたいもの

目指しているのは、エンジニアリングマネージャーになったばかりの人が、最初に短時間で読めて「だいたいこれぐらいやれば及第点を取れる」という内容です。

1トピックは短く
全体を30分、長くとも1時間で読み切れる
読んだ直後から使える

まずはこのブログに連載として書き、フィードバックにもよりますが最後に再編集して1冊の本にまとめられないかと思っています。¹

なお分量イメージとして近いのは『新1分間マネジャー』のようなサイズ感です。²

前提にする考え方

エンジニアやテックリードがマネージャーになるのは、ほぼ転職に近い変化だと思っています。求められるスキルセットが大きく変わるからです。

そのときに大事なのは、「唯一の正解」を覚えることではなく、文脈に合わせて使える手札を増やすことです。状況に応じて出せるカードが多いほど、現場で柔軟に対応できるようになります。もし手札が少なければ、毎回同じカードを出すことになり、うまくいかないときのリカバリーも難しくなります。

マネジメントに絶対の正解はありません。例えば、よくアンチパターンとして挙げられるマイクロマネジメントは必ずしも悪ではありません。マイクロマネジメントは平時には副作用が強い一方で、危機対応では有効に働く場面があります。厳しい状況では、壮大なビジョンを語るより、目の前のタスクをこなすことのほうが重要になることもあります。

これから扱うテーマ

今のところ、次のようなテーマを扱う予定です。

方向性を明確にして、理解と共感を得るのがすべて
環境を作ったうえで、信じて任せることの難しさ
ビジョン・戦略・戦術って結局何なんだ？
やらないことを決める重要性
「やめる」決断
意図的に採用に時間を使う
なぜ一人の責任者を決めることが重要か
なぜオーナーシップを持たせるべきか
自分がいなくても回る環境をどう作るか
1on1は有効だが必須ではない
ティーチング、メンタリング、コーチングの違いと使い分け
意思決定で多数決ばかり使わないほうがよい理由と、おすすめの決め方
マネージャーが背中を見せることで文化を築く
マネージャーが学ぶ姿勢を見せること、技術を追い続けること
マネージャーからICに戻るのは簡単ではない
信頼貯金をどう作り、どう使うか
メンバーに数年後のなりたい姿を言語化してもらう難しさと向き合い方
業績評価をどう伝え、どう納得を得るか
フィードバックを受ける/渡す技術
コミュニケーションを整えるための「取扱説明書」
判断基準や期待値を、できるだけ言語化すること
期待値を上げすぎない運用と、精神的ダメージを減らす考え方
権限が弱い状態で変化を起こす方法
社内外のネットワークがなぜ効果的なのか
ミーティングは少ないほど良い
定例ミーティングのなくし方
アカデミックな知見の活用方法と限界
ファシリテーション技術はレバレッジが効く
KPIなどのメトリクスをどう設計し、どう使い分けるか
セルフマネジメント：高いパフォーマンスを出し続ける方法
チームビルディングとふりかえり
組織デザインの基礎と「例外」を扱う視点
上司に活躍してもらう
他部署との共通言語の作り方
焦らない、楽観的に構えておく

実際に書いてみて、内容や順番は変わるかもしれませんし、このリスト自体も変わるかもしれません。最終的には、何らかの法則に沿ってカテゴライズすると思いますが、今のところは書けそうなところから書いていこうと考えています。

結局一番大事なこと

マネージャーの成果は「仲が良いチームそのもの」ではなく、どんな手段であっても、組織が出したいアウトカムを出せるかで判断されます。チームビルディングや合意形成は、そのための重要な手段の1つです。最前線でコードを書くことも、採用に時間を使うことも、部署をまたいで仲間を増やすことも、環境を整えて信じて任せることも、すべてはアウトカムを出すための手札の1つだと考えています。

というわけで、次の記事からは内容に入ってきたいと思います。お楽しみに！³

もし出版社の方で興味がありましたら、footerの連絡先までご連絡ください ↩
出版するには短すぎて難しいかもしれません ↩
反応次第で、ひっそりと終わる可能性もあります ↩

スクラムフェス大阪2025に登壇してきた

Sun, 27 Jul 2025 00:00:00 +0000

大変ありがたいことにお声がけいただいて、2025/7/19(Sat) スクラムフェス大阪2025のクロージングキーノートに登壇してきた。その時の資料は以下の通り、 SpeakerDeck にアップしてある。一部削っているが原則そのまま載せている。

全体は資料に譲るとして、1) 本記事では登壇に向けて何を考えていたか、 2) 登壇で特に伝えたかったこと、3) イベントで色々な方と話し、登壇を終えて考えていたこと、を記しておく。

登壇に向けて考えていたこと

月並みだけど、登壇の前はかなり不安になっていることが多い。当日はある程度開き直っているのだけど、それまでの数日が一番考え込んでいる。

ちなみに、クロージングキーノートで初めて登壇したのは RSGT2023 であった。RSGTのこれまでの歴代の講演を見て「これは本当に自分が話してよいのだろうか？」と、当時は心底思っていた。今回のスクラムフェス大阪でも同様に「期待に応えられるだろうか？」「この話で良いのだろうか？」と例に漏れず考えていた。結果、だいたい1週間前ぐらいから、ずっと悶々としながらストーリーを考えていた。

ストーリーを考える時は、ここ半年ぐらいのカレンダーを見直したり、読んだ書籍を見直したりしていると、伝えたいメッセージが出てくることが多い。すぐに出てこないとしても、通勤中だったり、ぼんやり買い物をしているときにふと思いつくことがある。なので、比較的新しい経験を思い出すのは一定効果があるのだと思う。

それとクロージングキーノートでいつも意識しているのは、クロージングまでのセッションで聞いた内容や、その日に廊下などでの会話を盛り込めないかどうか。今回も、直前で聴いていた@sasakendayoさんのセッションを引用させていただいたし、イベント前に参加者と話した内容を当日のトークに盛り込んでいた。

登壇で伝えたかったこと

今回のクロージングではいくつかメッセージを込めている。ただ、強いて1つ抜き出すとすれば、「自分を卑下しすぎなくていい」ということ。

なぜ、このメッセージを意図的に強調したいかというと、カンファレンスやイベントに参加するたびに元気をもらう一方で、「あぁ、これもできてないな」「〜さんのところはめちゃくちゃ頑張っている。あれは自分には難しすぎる」と凹むケースが個人的にあるためだ。特に聴いている内容によっては「それはそう！」「言ってることはわかる！だが実行に落とし込むのがしんどい！」と思っていることがよくある。

ただ、一方でそれでもやれる範囲で十分に頑張っている人がほとんどだと思う。みんな色々な環境条件・制約条件のもとで働いている。企業によっては予算制約が厳しいかもしれないし、別の企業では市場変化に苦しんでいるかもしれない。その十分な頑張りは、意外と認知・承認されることが少ない。というのも、同じ企業にいる別の同僚にとっては当たり前の制約であるためだ。

講演ではグッドウィルハンティングの1シーンの内容を引用させてもらった。ざっくり言えば「自分が選んでいなかった道は、なぜか困難や不確実性をないものとして考えてしまいがち。一方で自分が歩んできた道は苦労がわかっているから、公平に比較できない」という話。講演を聞いていると、他の発表者の講演が輝いて見えるのはこれが要因にあると思っている。

イベントで色々な方と話して、かつ登壇を終えて考えていたこと

まず前提として、イベント運営が素晴らしかった。（運営の皆様、大変お疲れ様でした＆ありがとうございました）

アジャイル系のカンファレンスやイベントに最後までいると、会場撤収の速さにびっくりすることが多い。どこか段取りが落ちていても、例外が即捕捉されて自律的に対処が進むのは見ていて本当にすごい。

それとは別に、色々な方と話していて思うのは、この同じイベントに参加している人同士であっても文脈が全然違うということ。ソーシャルメディアでは、一部の情報発信力の強い人や企業が目立つ。アルゴリズムもそれを加速している。ただ現実では、本当に色々な状態が存在しており、これはその条件で働いている中の人と話さなければ、全く気付けない。その話す機会を得られるというだけで、イベントに参加する意義があると思う。学べるところも多いし、もしかしたら相手にとって何かしら有益な話をできることもある。なので、不定期であっても参加して、他企業の方とどんどん話していきたい。

最後に、アジャイルラジオで話を伺っていた、みさコーチと少しでもお話しできたことが感激ポイントだった。かなり前のエピソードだったので、具体的に「どこに」を失念してしまってお伝えできなかったのが心残りだけど、今度の通勤でも復習したいと思う。

おわりに

というわけで、またどこかのアジャイル開発イベントでお会いしましょう！

LLM推論に関する技術メモ

Sun, 20 Jul 2025 00:00:00 +0000

はじめに

BentoMLによるLLM Inference Handbookという、LLMの推論をまとめたハンドブックがある。本記事ではハンドブックや他の情報も参照しつつ、自分のメモ用としてLM推論に関する技術をまとめていく。

LLMの推論と内部理解の必要性

LLM推論とは、GPT-4、Llama 4、DeepSeek-V3などの学習済みLLMを使用して、ユーザーの入力から意味のある出力を生成することを指している。その推論には、たくさんの技術が抽象化・隠蔽されている。APIを利用している場合は、ほぼ意識せず活用できる。しかし、APIを何らかの理由で利用できない場合や、Open WeightなLLMを利用したい場合はこれらの技術を理解する必要がある。

実際、最適化されていない設定では、GPU時間で10倍のコストがかかることもある。ユーザー面であっても、最適化がされていなければ、応答速度が遅くなり、UXが悪化する。

トークン化

トークンは、LLMがテキストを処理するために使用する言語の最小単位である。トークンは、利用するトークナイザー(Tokenizer)によって、単語、サブワード（単語の一部）などに変換される。

各LLMでは、独自のトークナイザーが使われているため、その内部のアルゴリズムも異なる。例えば、GPT-4oであれば この記事は iwashi.co に掲載されています。 という文字列は、 [117391, 5205, 43847, 28926, 10914, 147965, 137149, 196993, 788] というトークン列に変換される。合計のトークン数は9である。

ちなみにで、gemini 2.5 flashの場合は13トークンになる。この結果から、GPT-4o と gemini 2.5 ではトークナイザーが異なるため、そのままトークンIDを使いまわせないことがわかる。

推論の2フェーズ

GPT-4oのようなtransformerベースのモデルの場合、推論プロセス全体が2つに分かれていることを理解しておくと良い。

プレフィルフェーズ

1つ目のフェーズは、プレフィルである。動作は次のとおりだ。

（プレフィルの前に）ユーザーが送信したプロンプトを、トークナイザーがトークンのシーケンスに変換する
ここからプレフィルが始まる
まず先のトークン（あるいはTokenID）は、LLMが理解できる埋め込みベクトルに変換される。
次にそのベクトルは複数のtransformer層を通過する。その際の各層にはSelf Attention機構が含まれている。
- ここで、各トークンのクエリ（Q）、キー（K）、バリュー（V）ベクトルが計算される。
- 計算されたベクトルは、トークンが互いにどのように注意を向けるかを決定し、文脈的な意味を保持している
モデルがプロンプトを処理する際、全層のすべてのトークンのキーとバリューベクトルを保存するKVキャッシュを構築する。
- このキャッシュが、デコード中の高速検索のための内部メモリとして機能する

重要なのは、プレフィル段階では最初から全てのプロンプトがわかっている点にある（ユーザーがプロンプトを全て書いているのだから当然）。そのため、LLMは高度に並列化された行列演算、特にアテンション計算を通じて、すべてのトークンを同時に処理可能である。これはGPUの得意領域であり、compute-bound な処理になる。その結果、GPUの使用率が飽和する。（ただし、実際の使用率は、シーケンスの長さ、バッチサイズ、ハードウェアの仕様などの要因によって異なる）

このプレフィル、意識しておくべきメトリクスはTime to First Token（TTFT：最初のトークンまでの時間）である。プロンプトを送信してから、最初のトークンが生成されるまでのレイテンシを押さえておく。UXに直結する。

デコードフェーズ

プレフィルの次に来るのがデコードフェーズである。この段階では、新しいトークンがシーケンシャルに1つずつ生成される。自己回帰的に、前のトークン列から次のトークンを生成して、さらに生成したトークンを使って次に生成する、という動作を繰り返すフェーズとなる。

最後に、生成されたトークンのシーケンスは人間が読めるテキストに復号される。

プレフィルフェーズと比較した時のデコードフェーズの違いは、よりmemory-boundになる点になる。理由は、徐々に大きくなるKVキャッシュから頻繁に読み取りが発生するため。

仮にKVキャッシュを使わないと、全ての計算をやり直す必要がある。たとえば、「今日は良い天気」をプロンプトで入れた時の計算は

まず、「今日」「は」などのKとVをそれぞれ計算する
その情報を使って、次の単語を生成する
さらに、その次の単語を計算するために、再度「今日」「は」などのすべてのKやVを計算する必要がある。

しかし、KVキャッシュがあれば、最後の再計算は不要になる。¹

このKVキャッシュの仕組みは、上記のように冗長な計算を回避することで高速化を図る。しかし、キャッシュは生成されたシーケンスの長さとともに増大するため、メモリ消費の増加というコストを支払う必要はある。

デコードフェーズで監視すべき重要な指標は、Inter-Token Latency（ITL：トークン間レイテンシ）である。ITLは、シーケンス内の連続するトークンの生成間の平均時間をを示す。これはTime Per Output Token（TPOT：出力トークンあたりの時間）と呼ばれる。

ここまで説明したプレフィルとデコードは、シンプルなLLMサービングシステムだと、同じハードウェアで実行される。ただし、お互いの特性の違いから、並列に実行できない。その結果トークンレイテンシが長くなってしまう。そのため、プレフィルとデコードを分離する戦略が色々と探求されている。

API型 vs セルフホスト

LLMを使ったアプリケーションを作る場合は、マネージドAPI型とセルフホスト型の2つに分かれる。それぞれにPros/Consがある。

API型

OpenAI、Anthropic、GoogleなどのAPI型サービスは、インフラ管理を完全に抽象化しており、ユーザーは従量課金でLLMを利用できる。GPT-4やClaudeのような独自モデルだけでなく、Together AIやFireworksなどのプラットフォームでは、DeepSeek-R1やLlama 4などのオープンソースモデルもAPIとして提供されている。

API型の主な利点は次のとおり。

APIキーと数行のコードですぐに開始可能
- その結果、プロトタイプ向けのデモやツール作成に最適
GPU調達やスケーリングの面倒さを回避（委譲）できる

セルフホスト型

セルフホスト型は、クラウドGPUやプライベートVPC、オンプレミスで独自のLLMインフラを構築・管理する方式である。モデルのデプロイ、最適化、スケーリングを完全にコントロールできる。

セルフホストの主な利点は次のとおり。

データプライバシーとコンプライアンス。機密データ（医療記録、財務情報など）を安全に保てる
高度なカスタマイズ性
- レイテンシとスループットのトレードオフ調整
- プレフィル・デコード分離
- KVキャッシュ最適化
- 独自データを利用したファインチューニングによる優位性確保（の可能性）
外部APIのレート制限や突然のポリシー変更の影響を受けない

比較

どちらを選ぶかは、そのユースケースによって異なる。

項目	サーバーレスAPI	セルフホスト型推論
使いやすさ	✅ 良い（シンプルなAPI呼び出し）	⚠️ 悪い（LLMのデプロイとメンテナンスが必要）
データプライバシーとコンプライアンス	⚠️ 限定的	✅ 完全に制御可能
カスタマイズ性	⚠️ 限定的	✅ 完全な柔軟性
大規模時のコスト	⚠️ 高い（使用量ベース、大幅に上昇する可能性）	✅ 潜在的に低い（予測可能、インフラを最適化できる可能性）
ハードウェア管理	✅ 抽象化されている	⚠️ GPUのセットアップとメンテナンスが必要

コスト面での考慮

API型では、トークンあたりのコストは固定だが、使用量に比例して総コストが増大する。プロトタイピングには適しているが、本番環境では高額になることもある。

セルフホスト型では、初期のインフラ構築コストは高いが、スケールするにつれてトークンあたりコストは大幅に低下する。特に推論最適化技術（vLLMやSGLangなど）と組み合わせることで、コスト効率が向上する。

いつセルフホスト型を使うべきか？

基本的には、API型で始める方が良い。まずプロトタイプを作って、ユースケースやニーズを検証すべきであるため。ただし、パフォーマンス要件や、プライバシー、他者との差別化の重要性が高まるにつれて、セルフホスト型が考慮に入ってくる。

意識しておくべきGPUメモリ計算

LLMをサーブする場合に重要なのがGPUのメモリサイズだ。 LLMに関しては以下の2点を意識すると良い。

モデルサイズ（パラメータ数）。パラメータ数が大きいほど、必要なGPUメモリが異なる。
bit精度。FP16、FP8などのこと。bit精度が低いほどメモリフットプリントが小さくなるが、出力精度がイマイチになることもある。

必要なメモリサイズはざっくり以下のように計算すると良い。

メモリ (GB) = P × (Q ÷ 8) × (1 + オーバーヘッド)

- P：パラメータ数（単位は10億）
- Q：ビット精度（例：16、32）、8で割ることでビットをバイトに変換
- オーバーヘッド（％）：推論中の追加メモリまたは一時的な使用量（例：KVキャッシュ、アクティベーションバッファ、オプティマイザの状態）

例えば、20％のオーバーヘッドでFP16の70Bモデルをロードするには、次のように計算すれば良い。

必要なGPUメモリサイズ = 70 x (16/8) x 1.2 = 168GB

そのため、H100(80GB) x 1枚には当然載らない。そのため、複数GPUでの分散推論が必要となる。あるいは、INT8 や INT4へと量子化する方法もある。

LLM の量子化

量子化（Quantization）は、高精度フォーマット（FP32）などから、FP8やINT8へと変換して、必要なメモリを削減する & 推論を高速化する技術である。精度とサイズとの間にトレードオフは存在するが、適切に量子化できれば影響は最小限に抑えられる。

量子化フォーマット

ざっと以下で捉えておくと良い。

フォーマット	FP32比サイズ	精度低下	使用例	メモリ	備考
FP32	100%	なし	訓練	高	完全精度だが遅い
FP16	50%	最小限	訓練＆推論	中	ほとんどのLLMの標準
FP8	25%	低	訓練＆推論	低	まだ発展途上
int8	25%	低	推論	低	優れた万能トレードオフ
int4	12.5%	中程度	推論	かなり低	GPTQ/AWQなどの手法が必要

いつ量子化を使うべきか

量子化が適している場合は次のとおり。

限られたGPUメモリ（例：24GB以下）を持つハードウェアにデプロイする場合
推論レイテンシを小さくしたい場合
LLMのサービングコストを節約したい場合
同時実行する数を増やしたい場合
小さな精度のトレードオフを許容できる場合

一方で、量子化が適さない場合は次のとおり。

可能な限り最高の精度が必要な場合（例：センシティブまたは安全性が重要なタスク）
モデルがすでに小さい場合
デプロイ先のハードウェアが量子化フォーマットをサポートしていない場合

量子化手法

以下は広く採用されている量子化手法には次のようなものがある。

AWQ（Activation-aware Weight Quantization）

AWQは、すべての重みが同等に重要なわけではないという前提に基づいている。実際、重みの約1%が顕著に重要であり、そこに着目する。

実際には、次のようなイメージで量子化する。

学習済みのモデルを使って、実際のデータに対する各層の活性化（出力）がどのような値の範囲を取るのか、その統計情報（例えば、最大値や平均値など）を「オフラインで」収集する
次に、収集した活性化統計に基づいて、どの重みチャネルがモデルの性能に最も大きな影響を与えるか（つまり、量子化による劣化の影響を最も受けやすいか）を特定する
特定された「重要な重みチャネル」に対して、収集した活性化統計を考慮した「スケーリング」を行う
- スケーリングでは、モデル全体の出力結果を変えないような計算が用いられる
スケーリングされた重みを、より少ないビット数で表現するように量子化する

SmoothQuant

SmoothQuantは、量子化で厄介な「外れ値」問題の対処に焦点を当てている。

次のようなイメージで量子化を行う。

オフラインで、少量のデータを用いてモデルを実行する。ここで、各層の活性化の統計情報（特に最大値や分布）を収集する
- これにより、どのチャネルで活性化の外れ値が出やすいかを特定する
その結果を用いて、最終的な出力結果が変わらないように、重みを変換する

GPTQ

まず、PTQとは post-training quantization の略であり、事後学習量子化のことを示す。GPTQはPTQの1種である。

GPTQのコアは、各重みを1つずつ量子化していく際に、その量子化によって生じる誤差を、まだ量子化されていない他の重みを調整することで「補償」していくという点にある。

GPTQの面白い点は、3-4bitなどのかなり小さい精度での量子化を目指している点にある。その結果、例えば175Bのような巨大モデルであってもA100 x 1枚などで動作可能になる。

推論フレームワーク

モデルはそれ単体で動くのではなく、以下のような推論フレームワークと併用して使われる。イメージとしては、LLMが「脳みそ」だとすれば、推論フレームワークがそれを実行に移す「体」のような感じ。ただし、体を単に動かすだけじゃなくて、推論速度を高めるための技術や、同時リクエストへの対応など、さまざまな点で拡張されている。

代表的なものを以下に示す。

vLLM
- LLMのサービングに最適化された高性能推論エンジン。GPUリソースの効率的な使用と高速なデコーディング能力で知られている
SGLang
- LLMとVision LLM向けの高速サービングフレームワーク
LMDeploy
- 高速なデコーディング速度と同時リクエストの効率的な処理に焦点を当てた推論バックエンド
- 様々な量子化技術がサポートされている
TensorRT-LLM
- NVIDIAのTensorRT（高性能深層学習推論ライブラリ）を活用した推論バックエンド
- NVIDIA製なので、当然のことながらNVIDIA GPU上で大規模モデルを実行するために最適化されている
Hugging Face TGI
- LLMのデプロイとサービング用のツールキット
- Hugging Faceの本番環境で、Hugging Chat、Inference API、Inference Endpointを動かすために使用されている

よりコンシューマに近い環境では、次も候補になる。

llama.cpp
- 外部依存関係のない純粋なC/C++で実装された、LLM用の軽量推論ランタイム
- 名前にllamaとついているが、Llamaモデル以外にも、Qwen、DeepSeek、Mistralなど多くのアーキテクチャをサポートしている
MLC-LLM
- LLM用のMLコンパイラおよび高性能デプロイメントエンジン
- Apache TVMの上で動く。そのため、モデルをサービングする前にコンパイルと重みの変換が必要
- ハードウェアのサポート対象は幅広い
Ollama
- llama.cppの上に構築されたユーザーフレンドリーなローカル推論ツール
- シンプルさと使いやすさを重視して設計されており、最小限のセットアップですむ。例えばmacbook上でもすぐ動く
- vLLMやSGLangのようなランタイムとは異なり、同時リクエストはサポートされていない
  - この違いは重要
  - なぜならば、Paged Attentionや、Prefixキャッシュ、動的バッチ（複数のリクエストをまとめて処理する技術）などの多くの推論最適化手法は、複数のリクエストを並列で処理する場合にのみ効果的であるため

結局どれを選べばいいか？　という問いにあたるかもしれないが、全てのシナリオにハマるような単一のランタイム・ツールは存在しない。もし、複数リクエストを扱いたいならvLLMやSGLangが候補になるが、サクッと動かしたいならOllamaで良い。

推論メトリクス

すでにいくつか出てきたが、ここでは意識しておくべきメトリクスを整理しておく。

Time to First Token(TTFT)
- リクエストを送信してから最初のトークンが生成されるまでの時間。モデルがどれだけ早く応答を生成できるかを表現している
- UXに関連しており、LLMを分類機のように利用したい場合は、これが小さいほどUXが高まる
Time per Output Token(TPOT)
- インタートークンレイテンシ（Inter-Token Latency: ITL）とも呼ばれる
- 後続のトークンが生成される間の時間のこと
- TPOTが低いほど、モデルはトークンをより速く生成でき、1秒あたりのトークン数（Tokens per Second: TPS）が高くなる
- UXに直結する。TTFTがいくら小さくても、TPOTが遅いとUXはかなり厳しい
Token Generation Time
- 最初のトークンを受信してから最後のトークンを受信するまでの時間
Total Latency(E2EL)
- リクエストを送信してからユーザー側で最終トークンを受信するまでの時間
- 合計レイテンシは、TTFT + Token Generation Time で計算される

それぞれの時間は短いに越したことはないが、モバイルやWebのアプリと同様で、許容されるレイテンシーはユースケースによって異なる。例えば、リアルタイム対話が必要ならTTFTやTPOTは小さい方がいい。一方で、ドキュメント要約やDeepResearchであれば、即時性よりも正確性が重要になるだろう。

これらの数字は、単一の数値ではなく、平均値、中央値、パーセンタイルなどの指標で追うと良い。この辺のWebアプリの考え方と似ている。平均値だけを追うと、外れ値によって歪みが出る。その意味では中央値は、外れ値に対して耐性がある。

LLMのパフォーマンスベンチマークでは、平均TTFT、中央値TPOT、P99 E2ELなどのメトリクスがよく使われる。

スループット

LLM自体の実行速度を表すものとしてスループットがある。代表的なものに、Requests per Second (RPS：1秒あたりのリクエスト数)と、Tokens per Second (TPS：1秒あたりのトークン数)がある。

Requests per Second(RPS)
- LLMが1秒間に正常に完了できるリクエスト数
- 1秒あたりのリクエスト数 = 完了したリクエストの総数 / あるタイムフレーム（秒）
Tokens per Second(TPS)
- 入力TPS：モデルが1秒間に処理する入力トークンの数
- 出力TPS：モデルが1秒間に生成する出力トークンの数

バッチング

GPUは高度に並列化された計算処理のために設計されているため、1秒間に数兆回、あるいは数千兆回もの浮動小数点演算（FLOPs）を実行できる。だがLLMは、チップのメモリ帯域幅の大部分がモデルパラメータの読み込みに費やされるため、これらのGPUの性能を十分に活用できないことがよくある。

バッチんぐはそのボトルネック軽減に役立つ。どうやるかというと、名前の通りまとめて処理する。本番環境では、サービスに複数のリクエストが同時にやってくることがある。各リクエストを個別に処理する代わりに、それらをまとめてバッチとして処理することで、読み込まれた同じモデルパラメータを複数のリクエストで共有する。その結果、スループットを大幅に高められる。

そのバッチングにはいくつかタイプがある。

静的バッチング（Static Batching）

サーバーは固定数のリクエストが到着するまで待機し、それらを単一のバッチとしてまとめて処理する。実装が簡単だが、欠点もある。

バッチ内の最初のリクエストは最後のリクエストを待つことを強いられる。その結果、不必要な遅延が発生する。理想的な世界では、これがワークするかもしれないが、バッチ内のすべてのリクエストが同じように作られているわけではない。実際、LLMの推論では、一部のリクエストは非常に短い応答を生成する一方で、他のリクエストは長い段階的な推論を含む可能性がある。

動的バッチング（Dyanmic Batching）

静的バッチングに対応しようとしたもの。

動的バッチングでは、受信リクエストをバッチに収集するが、固定のバッチサイズにこだわらない。その代わりに、一定の時間枠（タイムウィンドウ）を設定し、その時間内に到着したリクエストをまとめて処理する。もし時間枠が経過する前にバッチがサイズの上限に達した場合は、その時点ですぐに処理を開始する。シャトルバスみたいなものを考えるとわかりやすい。乗車する顧客が少なければ定刻通り待つが、満席になったらすぐに出発するようなイメージ。

もちろん欠点がないわけではない。処理開始時にバッチが満杯でない場合もあるため、必ずしもGPUの効率を最大化できるわけではない。また、静的バッチングと同様に、バッチ内で最も時間のかかるリクエストがバッチ全体の終了時間を決定してしまう。その結果、短いリクエストは依然として不必要に待たされることになる。

継続的バッチング (Continuous Batching)

LLMの推論では、出力される文章（シーケンス）の長さはリクエストごとに大きく異なる。あるユーザーは簡単な質問をし、また別のユーザーは複雑で長い出力を求めるかもしれない。静的バッチングや動的バッチングでは、短いリクエストが最も長いリクエストの完了を待たざるを得ず、その間GPUのリソースは十分に活用されずに空いてしまう。

この非効率性を解決するのが、継続的バッチング（またはインフライトバッチングとも呼ばれる）である。

継続的バッチングは、バッチ全体が完了するのを待ってから結果を返す、ということはしない。その代わりに、バッチ内の各リクエストが独立して完了することを許容し、処理が終わったものから即座に新しいリクエストと入れ替える。これは、レストランの席のように、空いたらすぐに新しいお客様を案内するようなイメージ。

ここまで挙げてきたvLLM、SGLang、TensorRT-LLM、LMDeploy、Hugging Face TGIなどの主要な推論フレームワークはすべて、継続的バッチング（または同様のメカニズム）に対応している。

Paged Attention

LLMにおけるアテンション機構を実装する際の、メモリを効率的に使うアプローチである。

LLMが応答を生成している時、生成する各トークンごとに過去の情報（つまりKVキャッシュ）を記憶しておく必要がある。通常、KVキャッシュは1つの巨大な連続したブロックとして保存されるため、メモリの大きな部分を占有してしまう。これは、完全に使い切らない場合でも大きなブロックを予約する必要があるため、メモリのフラグメンテーションやメモリの無駄使いにつながる可能性がある。

Paged Attentionでは、大きな塊を、本のページのような小さなブロック（ページ）に分割する。さらに、このブロックはルックアップテーブルを利用する。（OSの仮想記憶管理とコンセプトは一緒）

PagedAttentionは最初にvLLMによって実装されたが、以降、Hugging Face TGIやTensorRT-LLMなどの他のプロジェクトもPagedAttentionを採用・実装している。

投機的デコーディング

高速な「ドラフト（下書き）」モデルと「ターゲットモデル（正確さが求められる）」を組み合わせることで、自己回帰的なトークン生成を高速化する推論最適化手法のこと。

これが有用なのは以下の2つの前提に基づいている。

文章の中には、予測が非常に簡単なトークンと、難しいトークンが混在している。簡単な部分は、小さなモデルでも十分に予測可能
LLMが文章を一つずつ生成していくプロセスにおいて、実は計算能力よりも、メモリからデータを読み書きする速度（メモリ帯域幅）がボトルネックになっている。そのため、GPUなどには、使われずに遊んでいる能力が余っている（投機的デコーディングは、この余剰能力を有効活用したい）

動作は次のようになる。

ドラフトモデルが入力シーケンスの後の次のKトークンを予測する
ターゲットモデルがこれらのKトークンを並列で検証し、自分も同じトークンを予測するかを確認する
ターゲットモデルは、自分が同意するこれらのKトークンの最長のプレフィックス（先頭部分）を受け入れる
h個のトークンを受け入れた場合、(h+1)番目のトークンを自分で生成する
このプロセスが繰り返される
- ドラフトモデルは、この新しく拡張されたシーケンスに基づいて次のKトークンを提案する

ただし、投機的デコーディングには独自のコストがある。ドラフトモデルとターゲットモデルの両方をメモリにロードする必要があるため、全体的なVRAM使用量が増加してしまう。

より実装含めた詳細は、同僚が書いた先読みを用いたLLMの文章生成の高速化があるので、そちらを参照されたい。

プレフィルとデコードの分離（Prefill-Decode Disaggregation）

冒頭で述べたように、LLMの推論ではフェーズが2つある。だいぶ前なので、ざっくりおさらいを書いておく。

プレフィル
- 全体のシーケンスを並列で処理し、アテンション層からのキーベクトルとバリューベクトルをKVキャッシュに保存する
- すべてのトークンを一度に処理するため、計算負荷はあるが、GPUメモリへの要求はそれほど高くない
デコード
- 先に構築したKVキャッシュを再利用しながら、出力トークンを1つずつ生成する
- プレフィルとは異なり、デコードは高速なメモリアクセスが必要だが、計算負荷は低い

この2つのステップを一緒に実行するのは、単純である。

しかし現実には、複数のリクエスト、しかもニーズの異なるリクエストが同時に到着することがよくある。だが、一度に実行できるフェーズは1つだけである。GPUが計算負荷の高いプレフィルタスクで占有されているとき、デコードタスクは待機しなければならず、これによりITL（Inter-Token Latency：トークン間レイテンシ）が増加する。逆の場合も同様である。

そこで、プレフィルとデコードを分離したい。2つの異なるタスクを分離して、お互いの邪魔をしないようにしたい。そうすれば、次の利点が得られる。

プレフィルとデコードを異なるハードウェア上で独立してスケジューリングしてスケールできる
- たとえば、マルチターン会話やエージェント型ワークフローなどが多い場合、KVキャッシュの多くを再利用できる
- その結果、プレフィルの計算負荷が下がり、デコードにより多くのリソースを割り当てられる
お互いのフェーズが干渉しなくなるため、効率的に並列で実行できる。（スループットが上がる）
TTFTとITLを最適化するために、プレフィルとデコードのそれぞれに対して異なる最適化技術（テンソル並列化やパイプライン並列化など）を実装できる

SGLang、vLLM、Dynamo、llm-dなどのオープンソースフレームワークやプロジェクトが、この分離に積極的に取り組んでいる。

ただし、もちろん銀の弾丸ではない。ワークロードが小さかったり、GPUが最適化されていなければ、パフォーマンスは逆に悪化する。また、プロンプトが短い場合や、デコード側で高いプレフィックスキャッシュヒット率が得られる場合は、デコードワーカー上でローカルにプレフィルを実行する方が、多くの場合、より高速でシンプルになる。さらに、当然のことながら、プレフィルワーカーとデコードワーカーの間でKVキャッシュを迅速かつ確実に移動させる必要がある。高速で低遅延な通信プロトコルをサポートするソリューションが不可欠になる。このデータ転送にかかるコストが高いと、かえって全体でパフォーマンスが下がってしまうかもしれない。

KVキャッシュAwareな負荷分散

従来のWebアプリでは、負荷分散は通常かなりシンプルである。リクエストは小さく、レスポンスは迅速で、どのバックエンドインスタンスでもどのリクエストでも同じように処理できる。ロードバランサーは、ラウンドロビンのような単純な戦略を使ってトラフィックを均等に分散できる。

しかし、LLM推論ではこれが全然異なる。主な理由は、プレフィル段階で使うKVキャッシュである。

従来のロードバランサーは、LLMワーカーを同一のブラックボックスとして扱う。各ワーカー内部で何が起きているかを把握していない。つまり、以下のような情報が見えていない。

KVキャッシュによってどれだけのGPUメモリが消費されているか
リクエストキューがどれだけ長いか

ロードバランサーが、上記を意識（Aware）できていなければ、次の問題につながる。

キャッシュ再利用の機会損失
- 類似したプレフィックスを持つ新しいリクエストが、既存のキャッシュされた計算結果を活用できない
レイテンシの増加
- 間違ったレプリカにルーティングされた会話は、KVキャッシュを失い、コストの高い再計算が必要になる
負荷の不均衡
- 一部のワーカーが多くの長い会話を処理する一方で、他のワーカーはアイドル状態のままになる

そこで、解決に取り組んでいるものもある。例えば、エンドポイントピッカーを使用して、各ワーカーのKVキャッシュ利用率、キューの長さ、LoRAアダプターに関する情報を収集し、より良い推論のためにリクエストを最適なレプリカにルーティングする。

プレフィックスキャッシング

「KVキャッシュ」という用語は、元々は単一の推論リクエスト内でのキャッシングを指す言葉であった。以前にも述べた通り、LLMはデコードの際、それまでに出力したトークンを基に次の新しいトークンを生成するという自己回帰的な（autoregressive）動作をする。つまり、自身のKVキャッシュを再利用している。このKVキャッシュがなければ、モデルはデコードの各ステップで過去のトークンに関するすべての計算をやり直す必要があり、これはリソースの膨大な無駄遣いになる。

このキャッシングの概念を複数のリクエストをまたいで拡張した場合、それをより正確に表現するのが「プレフィックスキャッシング（prefix caching）」あるいは「プロンプトキャッシング（prompt caching）」である。

この考え方はシンプルだ。ある問い合わせ（クエリ）のKVキャッシュを保存しておくことで、同じ冒頭部分（プレフィックス）を共有する新しいクエリが来た際に、プロンプトのその部分の再計算をスキップする。キャッシュされた結果を直接再利用することで、計算負荷を削減し、推論を高速化する。

例えば、次のようなシステムプロンプトを持つチャットボットを考えてみる。

あなたは有能なAIライターです。プロフェッショナルな態度で文章を作成してください。

このプロンプトは、会話の相手が変わっても、同じである。毎回この部分を再計算する代わりに、そのKVキャッシュを一度だけ保存しておけば良い。そして、ユーザーから新しいメッセージが届いた際には、この保存されたプレフィックスキャッシュを再利用し、プロンプトの新しい部分（ユーザーのメッセージ）だけを処理すれば十分だ。

プレフィックスキャッシュを認識したルーティング

しかし実際にプレフィックスキャッシングを適用するには、課題もある。

新しいリクエストを、適切なプレフィックスをすでにキャッシュしているワーカーに、どのようにしてルーティング（転送）するか？
ルーターは、各ワーカーのキャッシュに何が入っているかを、どのようにして知るのか？

そこで、OSSのプロジェクトが独自のアプローチを採用している。

ワーカーが報告するプレフィックスの状態を意識する
- Dynamoでは、ワーカーが自身がキャッシュしているプレフィックスを積極的に報告する
- ルーターはこのリアルタイムのデータを使ってルーティングする
ルーターが予測するキャッシュの状態
- SGLangでは、過去のリクエスト履歴に基づき、各ワーカーに対応する近似的な基数木（radix tree）をルーター側で維持する
- これにより、ルーターはワーカーから常に最新情報を受け取らなくても、どのワーカーが必要なプレフィックスを持っている可能性が最も高いかを予測できる
ハイブリッドな取り組み
- Gateway API Inference Extensionプロジェクトは、EPP（エンドポイントピッカー）上でルーティングアルゴリズムを実装するために、複数の戦略を用いる
  - Prefix affinity consistent hashing（プレフィックスの類似性に基づいたコンシステントハッシュ法）
    - 似たプレフィックスを持つリクエストを同じワーカーにグループ化する
  - ルーター上の近似プレフィックスキャッシュ
    - ルーターが、すべてのバックエンドサーバー上のプレフィックスキャッシュの近似的なルックアップキャッシュを保持する
  - ルーター上の正確なプレフィックスキャッシュ
    - モデルサーバーから報告されたKVキャッシュ情報を収集する
llm-dは、Inference Schedulerというコンポーネントを使用してフィルタリングとスコアリングアルゴリズムを実装し、キャッシュの可用性、プリフィル/デコードステータス、SLA、負荷などの要因の組み合わせに基づいてルーティングを決めている

並列

推論であれ、学習であれ、巨大な情報量を扱うLLMではさまざまな並列化手法が利用される。以下で簡単に紹介する。

データ並列

データ並列は計算を高速化するための一般的な手法である。

このアプローチでは、モデルの重みを複数のGPUデバイス間で複製し、グローバルなバッチの入力データをより小さなマイクロバッチに分割する。各デバイスは自分に割り当てられたマイクロバッチのみを処理し、このプロセスがすべてのデバイスで並行して実行される。

元のバッチ：[━━━━━━━━━━━━━━━━] (16サンプル)
            ↓ 4つのGPUに分割
分割後：
GPU1: [━━━━] (4サンプル)
GPU2: [━━━━] (4サンプル)
GPU3: [━━━━] (4サンプル)
GPU4: [━━━━] (4サンプル)

テンソル並列

テンソル並列は、モデルの個々の層をより小さなブロックにスライスする手法である。スライスされたブロックは独立した異なるデバイス間で並行計算される。例えば、行列乗算であれば、行列の異なるスライスを複数のGPUで同時に処理できる。

このアプローチのメリットは、高速化だけではなく、単一デバイスのメモリに収まらないLLMの推論を可能にする点にある。ただし、デバイス間で追加の通信が発生するため、この通信オーバーヘッドとパフォーマンス向上のバランスを取る必要がある。

パイプライン並列

パイプライン並列は、モデルの層を連続したいくつかの塊（チャンク）に分割し、それぞれを別々のデバイスに割り当てる。データはこれらのチャンクを「組み立てライン」のように流れ、あるデバイスの出力が次のデバイスの入力となる。例えば、4分割のパイプライン並列では、各デバイスがモデル全体の層の4分の1ずつを処理する。

しかし、各デバイスは前のデバイスの出力に依存するため、一部のデバイスが待機状態になる時間（バブルとも呼ばれる）が発生し、リソースの非効率な利用につながる。この待機時間を削減するために、入力バッチをさらに小さなマイクロバッチに分割する手法がよく用いられる。各マイクロバッチが次々とパイプラインを流れることで、GPUの利用率は向上するが、アイドル時間を完全にゼロにすることはできない。

なお、注意点として、パイプラインの各ステージ間で通信が発生するため、リクエストごとの合計レイテンシは増加する可能性がある。

補足：テンソル並列とパイプライン並列の違い

テンソル並列とパイプライン並列は、分割の仕方が根本的に異なる。テンソル並列は、層を複数に分割する。

元の層：[━━━━━━━━━━━━━━━━]
分割後：[━━━━][━━━━][━━━━][━━━━]
        GPU1  GPU2  GPU3  GPU4

一方で、パイプライン並列では、工程を分割する。

元のモデル：層1→層2→層3→層4→層5→層6→層7→層8→層9→層10→層11→層12
分割後：   [層1-4]    →    [層5-8]    →    [層9-12]
           GPU1            GPU2            GPU3

rebuild の hak さんの真似ると、パイプライン並列は説明しやすくて、

職人A（GPU1）: ひたすらシャリを握る
職人B（GPU2）: シャリにワサビを乗せる
職人C（GPU3）: ネタを乗せる
職人D（GPU4）: 最後に皿に盛り付けて出す

のように工程で割るイメージ。

エキスパート並列

エキスパート並列は、MoE（Mixture of Experts）モデルで使われる特殊な並列処理戦略である。

MoEモデルでは、入力されるトークンごとに、モデルの中の一部の「エキスパート」（専門家のような小さなニューラルネットワーク）のみが活性化される。エキスパート並列では、すべてのエキスパートを各デバイスに複製するのではなく、エキスパート自体を異なるデバイスに分割して配置する。

つまり、各GPUは、すべてではなく一部のエキスパートの重み全体を保持する。これにより、各GPUは、そのGPU上に格納されているエキスパートに割り当てられたトークンのみを処理するようになる。

ハイブリッド並列

ここまで述べた並列手法は、1つだけ使うのではなく複数使われることがある。ハイブリッド並列はまさに組み合わせた手法となる。

典型的なハイブリッド手法は次のようになる。

もし、8つのGPUがある場合、最初の4つのGPUにテンソル並列（TP=4）を適用し、残りのGPUにデータ並列（DP=2）を使う

ただし、これは可能な組み合わせの一つに過ぎず、それぞれに利点と欠点がある。上記の例では、テンソル並列はGPU間、特に推論中の通信オーバーヘッドを発生させる。そのため、高いTP度を使用することが必ずしもより良いパフォーマンスに繋がるとは限らない。

他にも、テンソル並列を減らしてデータ並列を増やす構成もある。例えば、TP=2、DP=4に設定する。これにより、GPU間の通信が削減され、推論時のレイテンシの低減にもつながる（可能性がある）。

ただし、落とし穴もある。モデルの重みはGPUメモリの大部分を消費する。特に大きなモデルの場合はそうである。テンソル並列を少なくすると、モデルを共有するGPUが少なくなる。そのため、KVキャッシュのための領域が少なくなる。これにより、プレフィックスキャッシングなどの推論最適化が悪化する可能性がある。

これらのトレードオフは、テンソル並列とデータ並列に固有のものではない。ハイブリッド並列計画を設計する際には、特定のモデルサイズ、ハードウェア設定、推論要件に基づいて異なる構成をベンチマークすることが重要である。銀の弾丸は存在しない。最適な戦略は、チューニングと実験を通じて見つけ出される。

インフラ面での高速スケーリング

本番環境でLLMの推論は、モデルのトレーニングとは全くの別物である。学習が予測可能でバッチングを基本とするのに対し、推論はリアルタイムのユーザー需要に基づいて実施される。多くの場合、トラフィックは突発的であり予測が難しく、レイテンシーの増加やダウンタイムが許されない。

トラフィックの急増時には迅速にスケールアップ/アウトし、アイドル時にはコスト削減のためにゼロまでスケールダウンする必要がある。クラウドと同じく、弾力性が重要になる。

コールドスタート問題

スケーリングの重要な問題が、コールドスタート問題である。

LLMをコンテナでデプロイするのであれば、あるKubernetesノードが特定のデプロイメントを一度も実行したことがない場合にこの問題が発生する。コンテナイメージがローカルにキャッシュされておらず、すべてのイメージレイヤーをゼロからプルして初期化しなければならない。

実際には、さらに細分化して次のように問題が表出する。

クラウドを利用している場合、クラウドプロバイダーが新しいインスタンスを割り当て、それをKubernetesクラスタに接続するまでにかかる時間がかかる。インスタンスの種類や空き状況によっては、30秒から数分、Nvidia A100やH100のような需要の高いGPUの場合は数時間かかることさえある
同様に、LLMのイメージは、多数の依存関係とカスタムライブラリのため、一般的なPythonジョブイメージよりもはるかに大きく複雑となる。クラウドプロバイダーが複数ギガビット帯域の帯域をスペック上は記載していても、実際のイメージダウンロード速度ははるかに遅いことが多い。その結果、イメージのプルには3〜5分かかることがある
モデルのロードに必要な時間は、そのサイズに大きく依存する。LLMは数十億のパラメータがあるため、レイテンシが増加する。
- Hugging Faceのようなプラットフォームは、高スループットのマルチパートダウンロードに最適化されていないため、大きなモデルファイルの取得に時間がかかる
- 推論を開始する前に、モデルファイルを完全にダウンロードしてディスクに書き込む必要がある。これにより追加のI/O操作が発生し、起動が遅延する

じゃあ、どうするかというと、たとえば次のような方法がある。

オブジェクトストレージの利用
- マルチパート並列処理により帯域幅をフル活用できる
FUSEの利用
- CPU boundな展開処理とディスクI/Oを完全回避
- ちなみに、FUSEは、Filesystem in Userspaceであり、カーネル空間ではなくユーザー空間でファイルシステムを実装できるLinuxカーネルモジュールのこと
ゼロコピーGPUロード
- モデルウェイトをコンテナイメージから分離
- リモートストレージから直接GPU VRAMへストリーミングする

モデルの重みをコンテナに書き込むかどうかで分岐があるが、そもそもコンテナストレージよりもオブジェクトストレージの方が早い。

メトリクス

スケール要否を判断するメトリクスには以下がある。

CPU利用率
- シンプルで閾値も明確だが、Pythonベースのワークロードの実際の負荷を反映しているわけではない
GPU利用率
- 理論上はCPUより関連性の高いメトリクスだが、実際には不正確
- nvml のようなツールは、サンプリング期間中にほんのわずかでもカーネルが実行されればGPUを「使用中」として報告してしまう
- その結果、早すぎるスケールアップや、キャパシティに対する誤った安心感につながることがある
QPS (1秒あたりのクエリ数、query per second)
- 従来のWebサービスで広く使われているが、LLM推論ではあまり役に立たない
  - なぜならば生成AIへのリクエストは、入力の長さや生成されるトークン数によって、サイズや計算コストが大きく異なるため
- その結果、QPSには一貫性がなく、オートスケーリングの調整には不向き
同時実行数
- キューの中に入っているか、あるいは処理中のアクティブなリクエスト数を表すこのメトリクスは、システム負荷を反映する理想的な指標となる
- 同時実行数はバッチサイズに基づいて簡単に設定できる
  - 実際のシステム需要と直接相関するため、正確なスケーリングに使える
- ただし、同時実行数が機能するためには、フレームワークが自動的に同時実行数をメトリクスとして計測しており、かつデプロイしているプラットフォームへのスケーリングシグナルとして情報を与える必要がある

推論インフラの構築・運用コスト

LLM推論インフラの構築は、単なる技術的なタスクではない。多大なコストと時間がかかる。本気が必要。

どれぐらい複雑か？

LLMの推論は、標準的なクラウドネイティブの技術スタックよりも遥かに多くが必要となる。例えば、以下を意識する必要がある。

高性能GPUのプロビジョニング
CUDAのバージョン互換性やドライバの依存関係の管理
オートスケーリング、同時実行数制御、スケールトゥゼロ（アイドル時にリソースをゼロにする挙動）の設定
GPUモニタリング、リクエストのトレーシング、障害検知のためのObservabilityツールのセットアップ
ストリーミング、キャッシング、ルーティングといったモデル固有の挙動への対応

これらのステップは、どれ一つとして簡単なものではない。こういった要求を汎用のインフラに無理やり当てはめようとしても、パフォーマンスの低下と開発期間の長期化を招くだけ。

たとえチームがそれをやり遂げたとしても、インフラのセットアップに費やした毎週の時間は、モデルを改善したり、製品価値を提供したりするために使われなかった時間になる。高いパフォーマンスを求められるAIチームにとって、この機会損失は、インフラの請求書と同じくらい現実的なコストになる。

MLツールとフレームワークの柔軟性の制限

多くのAI技術スタックは、モデルのランタイム（PyTorch, vLLM, 特定のTransformerなど）のバージョンを固定する。その主な理由は、コンテナイメージをキャッシュし、インフラ関連コンポーネントとの互換性を確保するためだ。これはクラスタへのデプロイを簡素化する一方で、新しいモデルやフレームワークをテスト・デプロイしたい場合に、柔軟性が失われる。

つまり、以下の制約が生じる。

新しいモデルやフレームワークのバージョンを簡単にテスト・デプロイできない
自社のスタックがコミュニティやベンダーのアップデートから乖離するにつれて、より多くの技術的負債を抱え込むことになる
LLMのデプロイ速度が低下し、チームが競争上の不利な立場に置かれる

複雑なAIシステムへの対応

LLMは、それ単体では価値を生み出さない。多くの場合、以下のような要素も必要になる。

ユーザー入力を整形・変換するための前処理
モデルの出力をフロントエンドで使えるようにフォーマットする後処理
モデルをロジック、パイプライン、制御フローでラップする推論コード
バリデーション、ルール、内部データ連携を処理するビジネスロジック
データベースや、特徴量を一元的に管理、共有、提供するための専門的なデータ基盤に接続するためのコネクター
RAGやアンサンブルパイプラインのための複数モデルの組み合わせ
他のチームが使いやすい形でサービスを公開するためのカスタムAPI

実際、ほとんどのLLMデプロイツールは、上記を考慮して作られていない。モデルの重みを読み込み、基本的なAPIを公開するように設計されているだけである。

そのため、一定以上に複雑なことをしようとすると、「グルーコード」やアドホックな対応策、あるいはロジックを複数のサービスに分割するといった対応が必要になる。その結果、次のような事態に陥る。

使える機能を提供するだけで、エンジニアリング工数がたくさんかかる
開発者体験が悪化する
ツールがユースケース固有のカスタマイズに対応していない場合、新規価値が作れない

人材の希少性

LLMインフラは、深い専門知識を必要とする。

企業は、GPU、Kubernetes、MLフレームワーク、そして分散システムをすべて一人の役割として理解しているエンジニアを必要するが、このような専門家は希少である。人件費も通常は高額になる。（従来のDevOpsエンジニアよりも高い）

LLMのオブザーバビリティ

LLMの推論を本番環境で運用するには、単にモデルが応答を返すだけでは不十分である。システムがすべてのレベルでどのように動作しているかを、完全に可視化する必要がある。オブザーバビリティがなければ、レイテンシーの問題、スケーリングの課題、あるいはGPUの低利用率といった問題を、雑に測することになる。

効果的なオブザーバビリティを実現するには、LLMの推論ワークロード特有の要求に合わせてカスタマイズされた、適切なメトリクス、ダッシュボード、ログ、イベントストリームが必要になる。

コンテナ & デプロイメント
- Podのステータス
  - 障害が発生した、スタックした、あるいは再起動中のPodを、可用性に影響が出る前に検知
- レプリカ数
  - オートスケーリングの挙動に関連。スケーリングの遅延や上限に関する問題のトラブルシューティングに役立つ
アプリのパフォーマンス
- 秒間リクエスト数（RPS）
  - 流入するトラフィックとシステムの負荷を測定し
- リクエストのレイテンシー
  - 応答の遅延やボトルネックの特定に役立つ
- 処理中のリクエスト数
  - 同時実行数を示す。アプリが需要に追いついているかを把握するのに有用
- エラー率
  - 失敗した、または無効な応答の割合。SLA監視に
- キューの待機時間
  - 利用可能なレプリカを待つことによって生じる遅延の把握に
クラスターリソース
- リソースのクオータとリミット
  - リソース使用量の上限をトラックする。リクエスト/リミット値の調整や、過剰/過小なリソース割り当ての回避に
LLM固有のメトリクス
- Token per Second
  - モデルのスループットとパフォーマンス効率を反映
- TTFT
  - UXに影響。ストリーミングやチャットのような体験では極めて重要
- Token Generation Time
  - 完全な応答を生成するまでのエンドツーエンドのパフォーマンスを測定
GPUメトリクス
- GPU使用率
  - GPUがどれだけビジー状態かを示す。低すぎる場合は、リソースの未使用やバッチングが非効率である可能性を示唆している
- GPUメモリ使用量
  - キャパシティプランニングや、OOMエラーの回避に有用

InferenceOps

InferenceOpsとは、LLMの継続的デプロイメント・更新・管理をサポートする実践とワークフローのことを示す。

まず、すべての本番LLMアプリケーションは、明確で再現性のあるデプロイプロセスから始めるべき。後々の緊急対応を避け、チームのどのエンジニアでも安全に変更をリリースできるようにするために役立つ。

さらに、従来のアプリケーションと同様に、モデルも自動的にパッケージ化、テスト、デプロイされるべき。モデルのリリース戦略も従来戦略が使える。つまり、カナリアリリースやブルーグリーンデプロイができる。

ある程度、自動パイプラインを作れたとしても、数個のモデルで機能する方法は、モデルが数十、数百に増えると、たちまち破綻する。特に、チーム、クラウド環境、ユースケースが多岐にわたる場合はなおさら。そこで、モデルレジストリやライフサイクルを一元把握できるようにする。

まとめ

かなり長くなってしまったけど、これぐらいを意識しておくと、LLMの推論を効果的にサーブできそう。

Kazuki679740569 さまにご指摘いただき、記載を修正しています。 ↩

「うーん、よくわからない。」という回答は情報価値が高い

Sun, 13 Jul 2025 00:00:00 +0000

はじめに

The Mom Testという、海外のプロダクトマネージャー御用たちの書籍がある。残念ながら、まだ邦訳は存在しないが、非常に有用な内容が詰まっている。

本記事では、3章の「Asking important Questions」を読み直している中で、自分なりの解釈や所感を自分用に残しておく。

重要な問い

ユーザーインタビューやソリューションインタビューを行う際の重要な問いとは、そもそも何か？　それは次のような問いである。

その答えがビジネスを完全に変える（または否定する）可能性がある
予期しない答えが返ってきても、やっていることに影響を与えない場合は、重要な質問ではない
会話の中で少なくとも1つの質問に恐怖を感じるべき

最後の「恐怖を感じるべき」という点はかなり興味深い。これは、自然と避けてしまいがちな傾向を表している。なぜ避けやすいかというと、「そもそも事業アイデアに根本的な欠陥があると判明するかもしれない」からだ。

重要な問いを避けている、悪いインタビューの例

仮に、読書アプリを開発しているとする。その際の悪いインタビューの例を挙げてみよう。

起業家：「読書習慣について話を聞かせてください。読書アプリを開発しているんです」
顧客：「実は本はほとんど読まないんです。時間がなくて」
起業家：「どんなジャンルの本なら、たまに読みますか？」
顧客：「えーっと、まあ、たまにビジネス書を手に取ることはありますが…」
起業家：「その場合に、読書アプリに欲しい機能は何ですか？読書進捗の管理とか、メモ機能とかどうでしょう？」
顧客：「うーん、よくわからないです」

これは完全にイマイチで、「本を読まない」といっているのに、読書機能についてどんどん質問してしまっている。

「うーん、よくわからない」という回答の価値

先ほどの例で挙げた「うーん、よくわからない」という回答は、実は非常に価値が高い。なぜなら、顧客がそのニーズに対して本当に関心がないことを示しているからだ。「それ、いいかもね」といった回答も同様。多分、顧客は全然惹かれていない。

こういったふわふわした回答こそが、真実を示すシグナルになっている。つまり、顧客がそのニーズに対して「本当に関心がない」「そもそもニーズを感じていない」ということを示している。

重要な問いを投げかける

読書アプリを前提にするのではなく、もっと幅広い視点で質問を変更して投げかけていく。

「読書に対して、本当にニーズを感じていますか？」
「読書にどれぐらいお金を使っていますか？」

いずれにせよ、顧客の優先順位を理解しようと試みる。「そもそも、本当にニーズがあるのか？」「顧客はそのニーズのために、時間やお金を使う意欲があるのか？」これを探っていく。

ニーズがないのであれば、ビジネスが否定される可能性がある。そうなったら、別の顧客セグメントに焦点を当てるか、ビジネスモデル全体を見直す必要がある。

良い掘り下げ方

「幅広く始めて、強いシグナルを見つけるまで焦点を絞らない」

これが基本原則。何か引っ掛かる部分（シグナル）が見つかったら、そこを掘り下げていく。

例えば、「今の大きな問題は何ですか？」「今、いちばん時間を取られていることは何ですか？」「いちばん気になっていることは何ですか？」といった質問から始める。

回答からシグナルが見つかったら、さらに掘り下げていく。そのために、

「その問題をどの程度真剣に考えていますか？」
「それでお金を稼いでいますか？」
「それでお金を稼ごうとしたことはありますか？」
「それに週にどのくらい時間を費やしていますか？」
「そのために使っているツールやサービスはありますか？」
「すでに改善のために何をしていますか？」

といった内容を聞いていく。これを継続的に探し続ける。その際、ビジネス全体の実現性を意識すべき。顧客が欲しがっていても、市場が小さすぎたり、競合が強すぎたりすると、ビジネスとしては成り立たない可能性があるため。

まとめ

重要な問いから逃げない
顧客のふわふわした回答を大切にする
シグナルを見つけて掘り下げる

12 Factor Agents まとめ

Sun, 06 Jul 2025 00:00:00 +0000

はじめに

Heroku社が提唱した「12-Factor App」は、クラウドネイティブなアプリケーション開発のベストプラクティスをまとめたものです。これをAIエージェント開発に応用して、dexhorthy氏がまとめたものが「12 Factor Agents」です。

この12 Factor Agentsを読んでみて、かなり学びがあったので、この記事では12 Factorの概要を簡単にまとめておきます。

なお、自分用にまとめて補足や所感を追加しているので、詳細はぜひ原文を参照してください。また、この記事は50%を人が書いて、50%をAIが補完しています。

12 Factor Agents の背景

「AIエージェントを作ろう！」

そう思って意気揚々とLangChainやCrewAIなどのフレームワークを使い始めた開発者は多いのではないでしょうか。最初は順調に進みます。デモは動くし、簡単なタスクもこなせる。でも、いざ本番環境に投入しようとすると……。

「品質が70-80%で頭打ちになる」

実際にプロダクションレベルで動かそうとすると、残りの20-30%が重要になります。ここで品質が落ちると、ユーザーの信頼を失い、ビジネスに悪影響を及ぼします。では、なぜAIエージェントはこの壁にぶつかるのでしょうか？

なぜそうなるのか？ - フレームワークの限界と現実のギャップ

多くのAIエージェントフレームワークは「プロンプトを与えて、ツールを渡して、ゴールに到達するまでループさせる」というパターンを推奨します。理論的には美しいアプローチです。でも現実はどうでしょうか？

# よくあるパターン
while True:
    next_step = llm.decide_next_action(context)
    if next_step == "done":
        break
    result = execute_tool(next_step)
    context.append(result)

このアプローチの問題点は以下のとおりです。

エラーが起きたときの制御が難しい
コンテキストウィンドウがすぐに溢れる
人間の承認が必要な場面で止められない
デバッグが地獄

実際、プロダクションで動いている「AIエージェント」と呼ばれるものの多くは、ほとんどが決定的なコードで、要所要所にLLMを使っているだけです。

12 Factor Agentsとは

そこで登場するのが「12 Factor Agents」です。これは、dexhorthy氏が提唱する、プロダクション品質のAIエージェントを作るための12の設計原則です。

重要なのは、これらの原則はフレームワークに依存しないということ。既存のコードベースに段階的に適用できる、実践的なパターン集という点です。以降では、この12の原則を簡単に紹介していきます。

Factor 1: Natural Language to Tool Calls（自然言語をツール呼び出しに変換）

エージェント構築において最も一般的なパターンの一つは、自然言語を構造化されたツール呼び出しへの変換です。

（所感：あまりによくあるパターンなので、あんまり意識しないかもで、詳細は割愛します）

Factor 2: Own Your Prompts（プロンプトを管理する）

プロンプトはコードと同じくらい大切な資産という原則です。一般的なエージェントフレームワークは簡単に始められますが、プロンプトの細かい調整やリバースエンジニアリングが困難です。フレームワークに隠されたプロンプトに依存するのは危険です。

プロンプトは明示的に管理し、バージョン管理し、テストすべきです。プロンプトは自前で書いて、関数形式で明確な入力・出力を持つファーストクラスのコードとして扱うのが良いでしょう。

Factor 3: Own Your Context Window（コンテキストウィンドウを管理する）

コンテキストウィンドウは有限のリソースです。「とりあえず全部入れる」では、すぐに限界が来ます。

// ❌ アンチパターン：履歴を全部入れる
const context = conversation.getAllHistory();

// ✅ 良いパターン：必要な情報だけを選別
const context = {
  recentMessages: conversation.getLastN(5),
  relevantDocs: search.findRelevant(query, limit=3),
  systemPrompt: prompts.getConcise()
};

また、LLMに渡す情報を普通のチャット形式ではなく、XMLやJSONなどの構造化された独自形式で整理して管理すると良いです。これによって情報密度が上がります。トークン数を削減でき、LLMがより正確に状況を理解して適切な判断ができるようになります。

（所感：コンテキストを絞るのは非常に大事なのと、XML などの意味が構造化された形式で渡すのはかなり効果的な印象）

Factor 4: Tools Are Just Structured Outputs（ツールは単なる構造化出力）

ツールが複雑である必要はありません。ツールは、LLMからの構造化された出力であり、決定論的なコードを実行するためのものです。LLMは何をするかを決定しますが、その実行方法は決定論的なコードによって制御されます。

従来の「AIにツールを渡して好きに使わせる」アプローチではなく、「AIには構造化されたJSONを出力してもらい、その内容に基づいて確実なコードを実行する」というアプローチが、実際のプロダクションでは信頼性が高くなります。

Factor 5: Unify Execution State and Business State（実行状態とビジネス状態を統一）

従来は実行状態とビジネスの状態の別々に管理していました。だが、この場合は不整合が起きやすいです。

エージェントの実行状態と、アプリケーションのビジネスロジックの状態を別々に管理すると、不整合が起きがちになります。

そこで代わりに、コンテキストウィンドウ（会話履歴）から実行状態を推測できるように設計します。

// ❌ 複雑な分離管理
const state = {
  execution: { step: 3, waiting: true, retries: 1 },
  business: { messages: [...], tools: [...] }
};

ではなく、

// ✅ 統一されたイベントストリーム
const thread = [
  { type: 'user_message', content: '...' },
  { type: 'tool_call', name: 'search', args: {...} },
  { type: 'tool_result', data: {...} },
  { type: 'waiting_for_approval', reason: '...' },
  // 現在の状態は最新のイベントから推測可能
];

とします。現在の状態は、イベント履歴を辿ればわかります。

Factor 6: Launch/Pause/Resume with Simple APIs（シンプルなAPIで起動・停止・再開）

AIエージェントも普通のプログラムと同じように、起動・一時停止・再開・停止といった基本操作を簡単にできるべきだという原則です。

これが必要な理由は次のとおりです。

効率性：無駄な待機時間を削減
信頼性：途中で止まっても安全に再開できる
統合性：他のシステムと連携しやすい
監視性：どの段階にいるかが分かりやすい

Factor 7: Contact Humans with Tool Calls（人間への連絡もツール呼び出しで）

LLMは「普通のテキスト」か「ツール実行」かを最初の1文字で判断しています。例えば、「その」から始まったら、文章が返ります。これが不安定な動作の原因になります。そこで、常にJSON形式で返すようにします。

その際、人間への連絡もツールとして扱います。イメージとしては、「エージェントが困った時に『ちょっと聞きたいことがあるんですが…』と人間に連絡してくるシステム」として作るということです。

Factor 8: Own Your Control Flow（制御フローを管理する）

AIに自動実行させると、さまざまな問題が起こります。たとえば、AIが「危険な操作」を選択した瞬間に、それを止める方法がないということです。また、長時間かかる処理の間、システムがメモリ上で延々と待機し続けるという非効率性もあります。データ分析が6時間かかる場合、その間ずっとプロセスが動き続け、サーバーリソースを無駄に消費します。さらに、途中でシステムが落ちれば全てが最初からやり直しになってしまいます。

そこで、AIの動作を3つのパターンに分けて、それぞれ最適な制御方法を適用します。

質問確認パターン：AIが曖昧な指示に困った時に人間に確認を求める
情報取得パターン：データ取得やファイル読み込みなど低リスクな操作を自動実行する
高リスク操作パターン：デプロイやデータ変更など重要な操作について、実行前に必ず人間の承認を求める

Factor 9: Compact Errors into Context Window（エラーをコンテキストウィンドウに圧縮）

AIエージェントの大きな利点の一つに「自己修復能力」があります。これは、何かの処理が失敗した時に、AIがエラーメッセージを読み取って自分で問題を解決する能力のことです。たとえば、AIがファイルを読み込もうとして「ファイルが見つかりません」というエラーが出た場合、優秀なAIなら「パスが間違っているかもしれない」「ファイル名にタイポがあるかもしれない」と推測して、修正した内容で再度実行をtryします。

エラーが起きた場合の実装方法もtry -> catchのloopで作れますが、無限リトライすると危険であるため、通常は最大リトライ回数を設定します。

ただし、エラーをそのままコンテキストに追加するだけでは不十分な場合があります。長いスタックトレースや複雑なエラーメッセージは、コンテキストウィンドウを圧迫し、AIの判断を混乱させる可能性があるためです。そこで、エラー情報を要約したり、関連性の低い過去のイベントを削除したりして、コンテキストを最適化してください。

Factor 10: Small, Focused Agents（小さく、集中したエージェント）

現在のAI開発でよく見られる間違いの一つに「万能エージェント」を作ろうとすることがあります。つまり、一つのエージェントにあれもこれもやらせようとする取り組みです。しかし、結果的に何もうまくできないエージェントを作ってしまうのがよくあるパターンです。

そこで、「一つのことを非常にうまくやる小さなエージェント」を作りましょう。

小さく集中したエージェントのメリットは次のとおりです。

コンテキストウィンドウが管理しやすいサイズに収まるため、LLMのパフォーマンスが向上する
各エージェントの責任範囲が明確になり、問題が発生した際の原因特定や修正が容易になる
個別のエージェントをテストすることで、システム全体の信頼性が向上する

Factor 11: Trigger from Anywhere（どこからでもトリガー可能に）

ユーザーがいる場所でエージェントが動くようにしましょう。

エージェントは、Webhook、CLI、API、Slack、メールなど、さまざまな方法でトリガーできるようにしてください。

（所感：DevinはSlackと連携するのを推奨していることから、原則に沿っていることがわかる）

Factor 12: Make Your Agent a Stateless Reducer（ステートレスなリデューサーにする）

最後の原則は、関数型プログラミングの考え方から来ています。

「AIエージェントは基本的にforループである」という前提があるとして、それを関数型プログラミング的に表現すると、AIエージェントは左foldになります。（reduce操作とも同じ概念）

（補足：ここでのタイトルのリデューサー/Reducerとは、「現在の状態」と「新しいアクション」を受け取って「新しい状態」を返す純粋な関数のこと）

まとめ

というわけで、ざっと12原則を紹介してみました。冒頭にも書きましたが詳細は、12-Factor Agentsの内容をぜひ参照してください。