導入

1. ローカルとクラウドの違い

2. 規約と見積書で止まった理由

3. 自社で持つ処理の決め方

まとめ

今回の記事と、ARC channel について

ARCHECO OFFICIAL

ローカルLLMとは？クラウドAPIとの違いと、社内に置く処理の決め方【超入門】

「賢さは借りられる、責任は借りられない」——全部を自社に置かず、持つべき処理だけを選ぶ

業務で使うAIがちゃんと答えてくれるようになった。でも「社内の情報をこのまま外へ送っていいのか」と聞かれると手が止まる。それならAIを全部社内で動かそうと見積もりを取ると、今度はサーバーの固定費が重くて進まない。
題材は、ARCHECOが作ったホテルの問い合わせ対応AI。1日数百件、応答2秒以内、3言語対応と要件は満たしていたのに、クラウドから自社へ移す検討は規約と見積書で止まりました。止まった原因は「所有するか借りるか」を全部まとめて決めようとしていたこと。問い合わせ対応という仕事も、中を見れば「種類を判定する処理」と「答えを組み立てる処理」に分かれるのです。

ローカルとクラウドの違い——比べる軸は性能ではなく「統制」とデータの行き先

ローカルLLMとは、AIのモデルを自社が管理する環境に置いて動かす構成のこと。高性能なAIの名前ではありません。クラウドは外部の事業者へデータを送り使った量に応じて支払う、ローカルは社内にデータを留める代わりに設備と運用を自分たちで持つ。利点はデータが外へ出ないこと、費用が使用量に比例しないこと、オフラインで動くこと、そしてモデルのバージョンを自分たちの都合で固定できること。毎回同じ判定をしたい分類の仕事では、この差が効きます。
欠点は高度な推論が苦手で、設備と速度に制約があり、初期費用と運用できる人が要ること。そこで出てくるのがSLM（小規模言語モデル）で、分類や抽出、定型の書き換えのように用途を絞った仕事なら実用になります。RAGとの違いも混同しやすいところで、RAGは答えの材料を検索して渡す仕組み、ローカルLLMはその計算をどこで行うかという構成の話。対立する選択肢ではありません。
設備ではGPUのVRAM容量が載せられるモデルの大きさを決め、同じモデル名でも量子化の種類で必要な設備が変わります。記事はまずGPUを買うより、手元のPCで小さいモデルを試すことを勧めています。組み込むならOllama、画面で試すならLM Studio。ただしひとりで快適でも、同時に使う人数が増えると待ち時間が出る点は要注意です。

規約と見積書で止まった理由——性能は足りていた

最初は対話AIのサブスクリプションを契約し、問い合わせをAPIに投げて返った文章をそのまま返し、難しいものだけ人へ回す構成でした。学習に使われないよう法人向けの契約にも切り替え、教科書どおりに進めたつもりだった。
止まったのは規約です。契約ではアカウントの共有が禁じられていて、サーバー経由で複数人が使う構成が認証トークンの共有に当たるのか、人格的な操作代行とみなされるのか。規約を読んでも黒とも白とも判断できなかった。法人契約で解決したのは「学習に使わない」という一点で、処理が向こうで走ることは変わっていなかったのです。自社で動かせる重み公開モデルも候補になりましたが、その中国発モデルには情報の扱いと倫理観の懸念が出て、ここでも止まりました。
だったら全部を自社で、と見積もりを取ると、GPUを積んだサーバーの費用を毎月持つ構造。使っても使わなくても出ていくお金が先に立つ。クラウドAPIなら使った分だけの従量課金で済む——この差が決定的でした。ローカルは無料になるわけではなく、API利用料が消える代わりに設備・電力・保守・モデルの入れ替えと再検証を引き受ける。量が増えるほどローカルが有利になる分岐点があり、記事の時点でARCHECOはその手前に立っていました。開発の見積書は総額でなく、構想・要件定義・実現可能性の検証・データ整備・運用のどこまでが含まれているかを見ることも語られます。

自社で持つ処理の決め方——振り分けだけを約100MBの小型モデルへ

問いは「この処理を外へ出した瞬間に、自分で責任を取れなくなるか」。社内の機密に触れるか、動きを固定したいか、止まると事業も止まるか。やったのは処理を分解し、振り分けだけを自社へ移し、残りは借りることでした。
種類の判定には専用の小さなモデルを作りました。容量は100MB程度。用途を絞ったことでGPU搭載サーバーが要らなくなり、振り分け精度は95%から97%に上がりました（この記事の、この用途での実績であり、小さいモデルで何でもできるという結果ではありません）。観光地の紹介文を作るところには自社で統制する理由がないので借りる。持つ部分を減らしたことで、固定費の問題が消えたのです。
記事の「統制権の棚卸しの表」は、最初の列に処理をひとつずつ書き、機密に触れるか・挙動を固定したいか・止まると事業が止まるかを確認する。全部いいえなら借り、はいが付いた処理を自社に持つ候補にします。サーバーを共有して基本料を割る案や仮想マシン案は、接続数の制御やアカウント管理など共有する側の運用を数えていなかったとして見送り。分岐点を動かしたのは共有して割ることではなく、小型化で設備を減らすことでした。そして持つ候補が見つかったあとも、運用できる人がいるかを確認します。

「賢さは借りられる、責任は借りられない」。AIが判断を担うほど、責任を持つ側は判断の土台を持ちたくなる。ただし責任を持つから全部を所有する、とはならない。全部を移すかではなく、どこを持てば責任を取れるか——この順番で考え、見積もりの前に処理ごとの理由を書いてみてください。なお規約の話は記事に書かれた当時の検討であり違反と確定した話ではなく、見積もりの金額も記事では伏せています。必要な設備やモデルの選び方、棚卸しの表は元記事に載っています。

10年間、大企業と新規事業を作ってきた ARCHECO（アルチェコ）が、自分たちのブログ記事を動画で解説しています。
紹介する事例は、記事と同じく公表された事実のみで、内部の事情や個人の責任は推測していません。
解説してほしい記事があれば、コメント欄で教えてください。

ローカルLLMとクラウドAPIの違いを、性能ではなく統制とデータの行き先、固定費と従量費の分岐点から解説。ホテルの問い合わせ対応AIが規約と見積書で止まり、振り分けだけを約100MBの小型モデルに移して精度95%→97%になった実例と「統制権の棚卸し」の進め方。

1. 図を描く前に決めること

2. 工程のあいだで消える時間

3. 受け渡しと停止点を表にする

業務フローの書き方 7ステップ｜図を描いても速くならないのは「待ち」を測っていないから

「図は間違っていないのに、直す場所が見つからない」——業務フローに描かれていなかった“待ち”

ARC channelの新シリーズは、ARCHECOが自分たちのブログ記事を動画で解説する回。今回の題材は、中古車の買取販売です。月の取扱台数は60台ほど、買い取ってから納車までは平均3週間。在庫が寝ると資金が回らず値落ちも起きるため、社長の目標は平均2週間。
担当者に話を聞き、部署ごとに帯を分け、工程を四角で囲んで矢印でつなぐ。全員が「この順番です」と納得する立派な図ができたのに、「どこを直せばいいか」と聞かれると話が止まる——。原因は図の描き方ではなく、仕事を遅くしているものが図に入っていなかったことでした。

図を描く前に決めること——目的・範囲・粒度、そしてスイムレーン

業務フローを描く目的を一言で言えるか。現状を共有したいのか改善したいのかで、必要な詳しさが変わります。記事がまず置く目的は「関係者の合意」。部署によって理解が違うので、図を見て「そこは違う」と言ってもらうためのものです。
業務フローは仕事全体が誰の手を通って進むか、ワークフローは申請から承認までの経路、マニュアルは作業のやり方。全体の順番と細かな操作を同じ図に詰めると読めなくなるので、作る前に目的・対象範囲・関係者・表記ルールを決め、粒度は「読み手が判断できる最小の単位」に合わせます。部署をまたぐならスイムレーン図。記号は四角（作業）・ひし形（判断）・矢印（流れ）など最小限にし、抜けを防ぐには管理者でなく実際に作業している人に「うまくいかなかったときはどうしますか」と例外から聞く。叩き台は表計算やスライドで十分です。
ここまでそろえれば関係者が確認できる図になります。けれど題材では、全員が納得した図を前にしても改善案が出ませんでした。整備にどれだけかかるのか、名義変更は書類を待つのか。順番の線だけでは、その答えが読めないのです。

工程のあいだで消える時間——作業を全部足しても数日、残りは図にない「待ち」

記事では工程ごとの所要時間を実際に測りました。車ごとにいつ次へ渡ったかを記録し、作業していた時間と手前で待った時間を分ける。すると査定や名義変更は分単位、整備は日単位で、作業時間を全部足しても数日にしかならない。買取から納車までの平均3週間との差のほとんどは、図に書かれていない待ちだったのです。
最も長かったのは名義変更に入る手前の待ち。買取の時点で印鑑証明・譲渡証明・委任状のどれかが足りず、事務がお客様に連絡して郵送を待っていた。図では買取から名義変更へ矢印が伸びているだけで、書類不足と届くまでの時間は箱の中に入っていません。
そこで記事は、工程と工程のあいだを主役にした「受け渡しの表」に書き換えます。渡す側・受け取る側・渡すもの・件数、そして一番右の「そのまま進められた率」（%C/A）。受け取る側が差し戻しも問い合わせも追記もせずに使えた割合で、渡す人の自己評価でなく受け取る人に聞いて測ります。この題材では営業から事務への受け渡しが群を抜いて低かった。作業を速くする話と待ちを減らす話を分けて見るこの方法は、バリューストリームマッピング（VSM）と呼ばれます。

受け渡しと停止点を表にする——「止める判断」と「あとから直せる判断」を分ける

確認が終わるまで何でも止めていないか。記事は人が判断する場所と止め方を「停止点の表」に整理します。査定の金額決定はお金が動くので止める、整備要否は費用が発生し、納車前の最終確認は取り消せないので止める。一方で書類の不備チェックは差し戻せて、出品価格はあとで変えられるので非同期でいい。判定基準は「金銭が動く・取り消せない・外部に送信される」。どれにも当たらない確認は、先に進めてあとから追認します。
営業から事務への受け渡しには、買取の場に書類チェックリストを画面に出し、そろうまで次に進めないようにしました。営業の手元の作業は少し増えましたが、事務が書類を待つ時間は目に見えて縮んだ。すると次に最も長く待つ場所は撮影の手前へ移ります。制約を狙って改善するとその場所は制約でなくなり、別の場所へ移る——制約理論の考え方で、改善は一回で終わらないので測り続ける仕組みを先に作るのです。
AIの置き場所も受け渡しの表から考えます。記事が挙げるのは、書類を撮影した画像から不備を自動判定すること。すでにそのまま進められる受け渡しより、欠損が多いところを狙う（実装結果の数字は記事にはなく、導入先の判断として読む）。

現場で始めるなら、受け渡しの表に担当者の役割・渡すもの・月の件数を入れ、そのまま進められた率は受け取る側に聞き、前工程の完了から着手までを日時で測る。停止点の表には、人が判断する場所と同期か非同期か、その理由を書く。図が完成したことを改善の完了にしないこと。遅い場所と情報が落ちる場所を特定できれば、道具は付箋でも表計算でもいい。「壁が寂しい問題にはまだ解がない」と記事は締めていますが、仕事を速くするのは表に残した実測データです。作図の記号やツールの選び方は元記事に詳しく載っています。動画とあわせてどうぞ。

業務フローを描いても仕事が速くならないのは、「待ち」が図に入っていないから。中古車の買取販売を題材に、作業時間と待ち時間を分けて測り、受け渡しの表（%C/A）と停止点の表で直す場所を見つける方法を解説。AIを置く場所の考え方まで。

冒頭ダイジェスト

オープニング

雑談から自然に聞き出す

直接聞きづらい相手にはどうする？

相手に合わせて相談の仕方を変える

まず落ち着いて整理する

AIを使って自分で考える

今すぐ聞きたいのに、聞けない時は？

聞けなかった時のリスクとフォロー

本日のまとめ

エンディング

Vol.10【3人本音会議】上司・先輩に聞けないことはどう解決してるの？

「AIに聞いて60点で動く」——上司・先輩に聞けないことの解決法

『3人本音会議』第10回は、この3人でのトークの最終回。五十嵐さんが引いたカードは「上司・先輩に聞きづらいことはどう解決している？」。
雑談にしれっと紛れ込ませる、聞きやすい人をクッションに挟む、まず落ち着いて分解する、AIを壁打ちにする、当たって砕ける——3人が実際にやっている5つの解決法が語られます。
聞かれる側の社長・熊澤さんの本音「ちょっとお話できませんか、は身構える」も必聴です。

雑談にしれっと紛れ込ませる——聞かれる社長側は「予告してほしい」

熊澤さんも山田さんも、直接は聞きづらいことを雑談の中でしれっと聞く派。仕事の話でも、あえて遠回りの話題から入る。「うまいね、俺もそれを言おうと思った」と息が合います。
一方で、聞かれる側の熊澤さんには社長ならではの本音が。「今日ちょっと話したい時間ありますか」が来ると、辞めたいのかと身構えてしまう。実際は結婚報告のような嬉しい話もあるので、事前に用件を軽く言ってほしい。文章に絵文字がついているかどうかで察するものの、当たったり当たらなかったり——というのが正直なところだそうです。
リモートや遠方で、予定が埋まっていて物理的に聞きづらい人には、五十嵐さんはワンクッションを挟みます。普段一緒に動いている年齢の近い人に「このことをあの人に相談したいんですが」と先に話すと、「この後ミーティングがあるから聞いておく」「それなら僕が分かる」と返ってくる。質問を投げれば返ってくる人もいれば、雑談のほうが返ってくる人もいる。相手に合わせて相談の仕方を変える柔軟性が大事で、日程調整でも「熊澤さんはすぐ予定に入れるので大丈夫、山田さんは絶対に忘れるので前日の夜に連絡する」という気遣いエピソードで盛り上がります。

まず落ち着く——絡まった問題を分解すると、本当に聞くべきは1つだけ

五十嵐さんが気づいたのは、「何でも聞いてしまう人」になるのは、自分が切羽詰まって訳が分からなくなっている時だということ。だから、まず落ち着くことを覚えた。
山田さんも同意します。若手の頃は武器がなく、どうしていいか分からないうえに、その問題のリスクや影響力も分からない。だからテンパる。でも焦って何でもかんでも聞くと、かえって詰められるケースもある。「まだ慌てる時間じゃない」と一度止まり、自分で考えても難しければ聞く。聞かずに自分でトラブルに立ち向かってみると、成功体験が積み重なることもあるといいます。

AIに聞いて60点で動く——上司側もその前提で接すると効率的

いまはAIという壁打ち相手がいる、というのが山田さんの視点。AIに聞けばひとまず回答が来る。仕事によってはそれで十分で、まずその通りに実行し、違うと思ったら修正して、60%のものを80%にしていけばいい。
人に聞くのは、相手が正解ややり方を持っていると思うからだが、その分お互いの時間もかかる。だったら「独自でもいいから、AIを壁打ちにしてまずやってください」という前提を上司も部下も持てると、この問題は実は解決されて、上司とのコミュニケーションの形も新しくなるかもしれない——「いいこと言った」と3人も納得の一言でした。
熊澤さんは「思い詰めるくらいなら聞けばいい」派。30分も1時間も悩んでいるなら、聞いたほうが早い。

今すぐ聞きたいのに、どうしても聞けない時は？ 山田さんの答えは「当たって砕ける」＋事後報告。体調を崩した熊澤さんの代打で、ほぼ初めてのワークショップを回した話も飛び出します。聞けなかったリスクは、打ち合わせ1回の進捗が思わしくないか、自分が恥ずかしい思いをするくらいで、よっぽど大事故にはならない。周りのメンバーに状況を共有して根回ししておけば「どうにかなる」——それも学習です。
まとめの五十嵐さんいわく、聞きづらいことは、他の人がどうしているかを観察し、雑談に紛れ込ませ、間に誰かを挟み、落ち着き、俯瞰して分解する。大きく絡まっていた問題も分解すれば、1つ目と2つ目は自分や検索で解決でき、本当に聞くべきは3つ目だけだったりする。3人の本音トーク、この顔ぶれでの最終回をぜひ本編でご覧ください。

アークチャンネルは、新規事業開発の実践者たちが好き勝手喋るVTRの内容を、スタートアップスタジオの先輩社員の神谷と、大学生インターンの五十嵐が
ゆるく、まじめに掘り下げていくトーク番組です。

・大企業特有の「新規事業の闇」
・スタートアップの人材採用や育成の舞台裏
・AI時代ならではの企画ノウハウ
など、『そこまで言っていいんかい！』な新規事業のリアルに切り込みます。

上司・先輩に聞きづらいことはどう解決する？雑談に紛れ込ませる、聞きやすい人をクッションに挟む、まず落ち着いて問題を分解する、AIに聞いて60点で動く、当たって砕けて事後報告。3人本音会議、この3人での最終回。

Video 11

Chapters

Video 12

Chapters

Video 13

Chapters