ClaudeとCodexは残し、文書仕事をローカルAIに移した開発会社

開発者がサービスのバグ修正をコーディングエージェントに頼む。まず元のチケットを探し、製品についての判断をいくつか取り出し、現在も有効な要件を見極める必要がある。修正後には、残った作業をデザイナーやサポート担当者が見られるチケットにする人も要る。コードの変更は仕事の一部だが、そのすべてを同じ有料モデルに任せている場合がある。

40人未満のソフトウェア会社Grayhat Developersは、2026年11月5日のプレプリントで、これらの仕事を分けたときに何が起きたかを紹介した。開発作業にセルフホスト型モデルを試したところ、商用のコーディングエージェントを置き換えると、リポジトリに関わる一部の作業が遅くなったり、難しくなったりした。複雑な変更には商用エージェントを残し、文書の検索・準備やチケットの同期の一部をローカルサービスに移した。

別の小規模チームなら、何から移すとよいだろうか。Grayhatの経験は、具体的な出発点と検討に値する見積もりを示す。また、モデルの品質を調べる前に試験を頓挫させかねない、導入時のつまずきも教えてくれる。

バグ修正はコードに触る前から手間がかかる

Grayhatは文書にOutline、作業管理にPlane、組織情報にERPNextを使っていた。すでにこれらを社内のマシンに置き、認証をAuthentikにつないでいた。Model Context Protocol（MCP）用のコネクターも同じマシンで動かし、モデルの推論は別のマシンが担当した。モデルの処理が別の場所で計算資源を使う間も、文書とチケットのシステムは通常の画面を提供し続けられる構成だ。

論文にある流れには、人による引き継ぎが含まれる。社内モデルでWikiや課題管理ツールの資料を検索し、要点をまとめる。必要な部分は、コーディングエージェント用にリポジトリ内のファイルへ書ける。リポジトリで作業した後は、次の手順を社内アシスタントに持ち帰り、チケット案にして管理ツールへ送る。論文では、エージェント同士の直接通信は今後の課題だ。現状でも人が境界を通る情報を確認し、渡してよいものを選べる。

Grayhatの作業で引き継ぎが起きる箇所。11月5日の事例をもとにしたTelli.shオリジナル図解。

顧客から「エクスポートで行が重複する」と報告があったとする。元の報告には非公開のアカウント情報や、バグと無関係な会話記録も含まれる。ローカルアシスタントなら、現在の出力ルール、サービスの担当者、以前の回避策を探せる。技術者は架空の再現データと期待する行数だけを要約に書く。コーディングエージェントは再現に必要な情報を受け取り、何を渡すかを人が選ぶため、機密情報は社内にとどまる。

社内向けの下書きには元のリンクを添えておく。要件が食い違ったとき、提案されたルールが最近の判断に基づくのか、古い回避策なのかを確認できる。ローカルで生成した要約でも出典がなければ、解決したい問題を再び作ってしまう。次の担当者がどの記述を信じるべきか調べることになる。

チームは利用枠を購入し、移せる作業を見積もった

著者らが報告する商用AIの基準費用は月約325ドルで、Claudeの7席に約175ドル、Codexの7契約に140ドル、クレジットに10ドルだった。サービス全体では、259.3億超のトークンを記録したとも述べている。記録されたトークンと325ドルが同じ請求期間に対応するかは、論文から分からない。それぞれの数字は測っているものに沿って使い、割り算でトークン単価を出す用途には向かない。

Grayhatは、文脈の受け渡し、文書作業、プロジェクト調整が商用AIの作業量の30～40%と見積もった。著者らによれば、この分類の約90%はローカルで担える可能性がある。掛け合わせると、商用AI全体の27～36%になる。これを325ドルに対する割合として換算すると月約88～117ドルだ。どちらも11月5日の事例が示す作業量と費用換算の推定で、論文は導入前後の請求額を統制条件で比較していない。

作業の割合から費用換算を求めたGrayhatの試算。Telli.shオリジナル図解。

席単位の課金ではこの違いが重要だ。複雑な作業のために開発者7人が引き続き契約を必要とするなら、利用量を減らしても次の請求額は変わらないことがある。別の修正に使える余裕、上限への圧迫の減少、追加購入の削減として効果が出るかもしれない。リクエスト単位の課金なら、変化は早めに出る可能性があるが、再試行や待ち時間が節約分を相殺することもある。新しいGPUと保守担当者が必要なら、その費用も比較に入る。

見直せる分母を選びたい。チケット案の数は数えやすいが、責任者が最初から書き直すなら節約の根拠にはなりにくい。採用された要約とチケットを数え、作業の意味を変えた編集を記録する。確認者が一貫して合格と判断できるようになったら、その成果を作るのに必要な手間を測る。

二つ目の画面では設定を担う人が変わった

初回の導入ではLobeHubを使った。技術者は手順を受け取り、それぞれの画面を組織内のツールにつなぐ必要があった。著者らによると、デモの感触はよくても日常の利用にはつながらなかった。どのコネクターを選び、どこにあり、どう認証するかを利用者が知る必要があり、選択が増えるたびに最初の有用な回答が遠のいた。

二つ目の画面では業務ツールを一元設定した。Saad Ahmed Bazaz、Talha Amjad、Abdurrehman Subhani、Sohaib Ahmed Bazaz、Abdullah Aamirによる「Create Your Own Work Stack」の図2。CC BY 4.0。

チームは一元設定したLibreChatに切り替えた。利用者は設定済みのツールを確認し、アクセス時に認証できる。著者らは初版について11件の構造化インタビューを実施し、設定と導入に関する意見を8件数えた。二つ目の版では、構造化していないDiscordのフィードバックで同じ分類の意見が3件あった。集め方が違う数字だ。導入の問題を把握する手がかりにはなるが、利用がどれだけ伸び、問題を感じなくなった社員が何人いたかは分からない。

初回は、実際にある一番小さな仕事を中心に設計する。課題の受け入れ条件を調べたい責任者なら、管理ツールがつながっていて、どのアカウントで使っているかが分かるとよい。チケットを三つ作りたい技術者なら、送信前に下書きを確認できるとよい。自分の仕事を見つける前にコネクターの設定を覚えさせると、役立つかどうかより、利用者の我慢強さを測ることになりかねない。

一元設定には新しい責任も伴う。承認済みのコネクター一覧を管理し、認証情報を更新し、誰が権限を変更できるかを説明する人が必要だ。そうでなければ、一人の設定ミスが全員の問題になることもある。逆に、繰り返す設定の問題を一度直せば、同じサービスの利用者全員に修正を届けられる。

成果の責任者が明確な仕事をローカルに任せる

課題の仕分けは実用的な候補だ。社内アシスタントは重複しそうな報告をまとめ、元のチケットへのリンクを添えた要約を提案できる。プロジェクトの担当者は、本当に重複しているか、まとめた説明で条件が落ちていないかを判断する。分類理由のコメント案も作れる。更新の責任者が見えるので、人は何が起きたか把握できる。

文書の保守は別の仕事だ。設定をある画面から別の画面へ移したとする。アシスタントは古くなったヘルプ記事を見つけ、どの製品エディションを対象とするか調べ、修正を提案できる。編集者が現在の画面遷移を確認し、正しい変更を公開する。難しいのが最新の社内ページへのアクセスと各記事の対象範囲の維持なら、さらに強いリモートモデルを使う価値は大きくない。

複雑な実装は対照的だ。データベース移行では、過去のデータ仕様を調べ、複数サービスを修正し、ロールバックを確かめることがある。Grayhatが試したローカル構成では、大規模なリポジトリ作業で、特に広い文脈とすばやい推論が必要なときに苦戦した。研究が示すのは、同社の機材、モデル、経験だ。担当範囲を広げる前に、自分たちの仕事で試す根拠になる。

単純な整形と機密データが混じる仕事には、経路を制限する。元のツールが社内で動いていても、下書きを外に送れば情報が露出することがある。外部への引き継ぎが必要なら、送信先を承認し、そこに必要最小限の資料を作る。社内の結果が未承認なら内部のレビュー待ちに残す。時間切れのときは、予期しない転送を起こさず、分かる形でエラーを示す。

短い予備試験で仕事の価値と運用の手間を分ける

1. 三つの成果物を定義する。 元のチケットにリンクした要約、文書の修正案、新規課題の下書きを選ぶ。それぞれを誰が受け入れ、どんな証拠が必要かを一文で書く。良い例に加え、見落としやすい誤りを含む失敗例も残す。
2. 現在の流れを測る。 普段の一週間で、完了した件数、内容の修正回数、文脈を探す時間を数える。可能なら商用AIの利用を作業フローごとに記録する。移行で請求対象の席数や超過費用が本当に変わるかも見ておく。結局やらなかった仕事は別に記録する。
3. 社内ツールを一つ接続する。 名前の明確なプロジェクトに対して読み取りから始める。権限のある社員が既知の課題を検索でき、対象外の社員はできないと確認する。もともと選んだ仕事を担当する少人数に絞り、失敗時は手作業で終えられるようにする。
4. 書き込みを許す前に下書きを比べる。 同じ人が同じ基準で採用か却下かを判断する。間違った課題へのリンク、古い事実、根拠のない結論を記録する。実際の管理ツールへの書き込み権限を渡す前に、プレビュー、承認、保存される記録を用意する。
5. 何が移ったか調べる。 採用された成果、確認時間、実利用、請求書を比べる。機器の保守、停止時間、コネクターの変更にかかった時間も足す。利用者への設定支援も含める。専門家が一人ずつ10分教えて初めて使えるなら、導入コストは残っている。

すでに開発者向けにローカルモデルを運用しているなら、普段の利用と並べて試す。同時に何人も始めたときに待ち行列ができ、一件の応答は速くても三人が待たされることがある。時間に余裕のない仕事では進捗を見られ、通常の手作業に戻れるようにする。仕事に合う範囲を学んでいる間も、予備試験を使い続けられる。

Grayhatの付録には比較の目安がある。業務ツールのマシンはシステムメモリー16 GB、推論用は32 GBと、VRAM 16 GBのRTX 4080だった。運用上の必要に応じて、ネットワーク監視、スケジューリング、無停電電源装置も加えたという。モデルに回答させる費用に加え、同僚が頼るサービスを運用するための観察であり、予備試験の予算に生かせる。

次の1時間のAI作業をどこに置くか決める

応用できるのは、文脈を整える作業と専門的な推論を分け、引き継ぎごとに責任者を置くことだ。頻繁に繰り返し、チームがすでに確認方法を知っている成果を作る仕事から始める。採用までの手間を測ってから、ローカルに次の仕事も任せるか決める。Grayhatの事例なら、今も価値のあるコーディングツールを使い続けながら、その判断を試せる。

出典

• Grayhat Developersのプレプリント、2026年11月5日
• 作業量の試算、インフラと図2を含む論文全文
• 図2の元画像
• 論文の図のCC BY 4.0ライセンス

---

引き継ぎに至った話し合いを検索できる記録に残すなら、Telli.shのアカウントを作成できます。