AI利用が散らばる前に、仕事の型ごとに整理する。

開発部門・情シス。CLI系AIツール、クラウドAI、ローカルLLM、MCP を部門に配りたい。

各自のPCにツール、APIキー、ログ、設定が散在し、導入支援・更新・棚卸しが重くなる。

• → 通常ルームを社員ごとの管理されたAIワークスペースとして配る
• → Claude Code / Codex CLI などのAIツール、クラウドAI、ローカルLLMを社員PCへ個別導入せず使える
• → MCP、APIキー、実行ログを組織側で管理しやすい場所に集約する

営業、管理、開発、情シス。調査、定時実行、長時間タスク、秘書的な作業をAIに任せたい部門。

個人PC上で動くAIタスクは、端末のスリープ、再起動、ネットワーク状態に左右される。引き継ぎやログ確認もしづらい。

• → 常駐エージェント、定時実行、長時間タスクをワークスペース側に残す
• → 通常業務・開発・調査・秘書業務を通常ルームで扱う
• → 作業の実行ログを社員PCではなく、組織が確認できる場所に残す

受託開発会社、SIer、情シス子会社。顧客ごと・案件ごとにコード、ログ、AIツール利用を分けたい。

案件をまたいでツール設定やログが混ざると、説明責任、棚卸し、退職・異動時の引き継ぎが難しくなる。

• → 社員ごと・案件ごとにAIワークスペースを分ける
• → Claude Code / Codex CLI などを使う通常開発と、未公開コードや閉域ログを扱う機密作業を分離する
• → 誰が・どのワークスペースで・何をしたかを確認できる前提を作る

顧客データ、社外秘文書、未公開コード、閉域の運用ログを抱える部門。クラウドAIへそのまま送れないデータがある。

禁止だけでは便利さに負けてシャドーAIが起きる。一方で、本番機密情報を扱う構成は個別の確認が必要。

• → 機密ルームは、扱えるデータと外部経路を通常ルームと分ける
• → 原則ローカルLLM中心で、外部送信や接続を制限したAIワークスペースを設計する
• → より強い境界が必要な場合は、企業専有・閉域やオンプレミスを検討する

AIツール実行基盤を小さく試したいが、将来はチーム展開や自社専有環境も検討したい企業。

最初から専有環境の要件定義を始めると重い。一方で、本番の機密情報をクラウドで扱えると過度に期待するのも危険。

• → デモ実演とPoCで、Hokoの基本体験と実環境相当の適合性を確かめる
• → チーム・部門に広げる場合の利用規模と運用要件を整理する
• → 境界要件が強い場合は、企業専有・閉域を含めて個別に設計する