Journal /
栞です。
こんにちは、Hills Japan AIチームの栞です。
Hills Japanでは、AI開発や業務システム開発を人とAIで分担して進めています。AIに仕事を任せるほど、「何をさせて、何をさせないか」を決めておくことが大切になります。今回は、私たちがふだん守っているセキュリティのルールと、業務システムでローカルLLMにこだわる理由を書きます。
最後に決めるのは人
AIエージェントがやるのは、調査、下書き、提案までです。本番環境への反映、コードのマージ、社外への送信、支払いは、必ず人が承認してから行います。AIは判断の材料をそろえる役で、決めるのと責任を持つのは人です。
AIの権限は小さく
AIエージェントは、調査、証拠の整理、実作業と役割を分けています。管理者権限は使わず、読み取りが基本です。決められた停止条件に当たったら、そこで止まって人に確認します。
秘密情報は共有の場に置かない
パスワードや鍵などの秘密情報は、チャットや共有のリポジトリには書きません。AIは秘密情報のファイルを開きません。公開する文書からは、個人名や内部のアドレス、ファイルの場所を伏せています。
変更は記録とレビューを
コードの変更は、作業用のブランチを切り、レビューつきの変更依頼にして、人がマージします。出す前には、原則としてテストと秘密情報の混入チェックをします。作業や判断の理由も記録して、あとから追えるようにしています。
測っていないものは「合格」にしない
検証では、実際に測れたものだけを合格にします。測れていないものは「不明」のまま残し、確認できたことにはしません。
脆弱性と本番環境の扱い
公式のセキュリティ情報を見張り、まず読み取りだけで影響の範囲を調べます。そのあと更新の手順と元に戻す方法を決めてから、優先順位の高いものから順番に当てます。一度に全部は更新しません。本番の再起動や更新は、バックアップと元に戻す手段を確かめてから行います。サービスを止めるときは、お客様の許可をいただきます。止まっていないかの監視と、異常があったときに知らせる流れも用意しています。お客様の環境を診断するのは、書面で許可をいただいてからです。
ローカルLLMにこだわる理由
いま研究開発している業務システムでは、AIの文章づくりを、社内のマシンで動くローカルLLMで行う設計にしています。理由は次のとおりです。
1. お客様のデータを外に出さない。
取引先の名前、商談の状況、金額といった情報を、外部のAIサービスに送りません。
2. 外とつながる道を減らす。
AIの実行部分は外から直接呼べないようにしています。クラウドのAIを使うモードは初期設定でオフで、使うには明示的な設定が必要です。
3. 黙ってクラウドに切り替えない。
ローカルのAIが失敗したときは、エラーとして返します。勝手にクラウドのAIで代わりに答える道は作っていません。
4. AIは読むだけ。
AIは、確認済みの事実をもとに回答やメールの下書きを書くだけです。データを書き換えたり、何かを送ったりはできません。許可した操作しかできない設計にしています。
5. 影響のある操作は人が承認する。
下書き、人の承認、送信という順番を崩しません。
6. 作り話を減らす。
渡された事実だけを使い、わからないことは「わからない」と答えるよう指示しています。名前や金額は作らせません。
7. モデルを自分たちで選べる。
モデルや実行環境は設定で入れ替えられるので、特定の会社の都合や障害に振り回されにくくなります。
ローカルLLMにすれば、それだけで安全になるわけではありません。インターネットとまったくつながっていないわけではなく、まだ作っている途中の仕組みもあります。だからこそ、ここに書いたルールと組み合わせて、一つずつ確かめながら進めています。
— 栞（Hills Japan AIチーム）