独立して6社を並行する情シスが、2日でAIエージェントチームを作った話【実録】

独立して2か月、気づけば6社の情シス業務を並行して支援していた。

端末管理の導入、前任からの引き継ぎ、アカウントの棚卸し、ライセンスの見直し、ヘルプデスク。1社ずつ見ればいつもの仕事だ。だが6社が同時に動くと、最初に限界が来たのは作業量ではなかった。「記憶」だ。

そこで、Claude Code で自分専用のAIエージェントチームを組んだ。構想から稼働まで2日。この記事では、何を作ったかよりも「なぜそう設計したか」を中心に書く。

▼6社を並行すると、最初に溢れるのは「記憶」だった

情シスの仕事は、小さな約束の積み重ねだ。「この端末のライセンス、来週までに確認します」「その件はベンダーに聞いておきます」。1社なら頭の中で持てる。

現場が6つになると、こうなる。

• ▶ どの会社の誰に、何を返したかがあいまいになる
• ▶ 会議で決まったことと、自分のメモがずれていく
• ▶ 忙しい時期が会社ごとにずれるので、ある社に集中した翌週は、別の社の文脈を思い出すところから始まる

それまでも、Claude のプロジェクトを会社ごとに分けて相談相手にはしていた。ただ、それは「聞けば答えてくれる」状態で、自分が聞かない限り何も動かない。必要だったのは相談相手ではない。事実を記録し、整理し、抜けを指摘してくれるチームだ。

▼ロールは、人のチームと同じ「職務分掌」で切った

最初に決めたのはロールの切り方だ。AIだからといって特別な分け方はしない。人のチームを組むときと同じ「誰が何の担当か」で切った。そうすれば、仕事を頼むときに迷わない。

区分	ロール	やること
自分の事業	秘書	カレンダーの整理。作業の予定がそのまま稼働記録になるよう、命名ルールを守らせる
自分の事業	議事録係・ナレッジ係	会議メモから議事録を作り、決定事項を各社の前提資料に反映する案を出す
自分の事業	リサーチャー・ライター・編集・会計・営業など	調査、記事の下書きとチェック、請求準備、提案文の下書き
クライアントごと	PM	その会社で動いている仕事を一覧にし、各担当に振り、成果物をチェックする
クライアントごと	現状調査	管理画面を読み取り専用で調べ、アカウント・端末・ライセンスの実測値をまとめる
クライアントごと	チャット確認・返信案	Slack / Teams の自分宛てを仕分け、返信の下書きを作る
クライアントごと	アカウント管理・購買・ヘルプデスク・各領域のオペレーター	入退社の準備、見積比較、問い合わせの一次回答案、端末管理・ID管理・ISMS などのプロジェクト実務

全部で20ロールになった。ただし、最初から細かく分けすぎてはいない。プロジェクトの実務担当は汎用の1ロールを基本にし、すでに複数社で案件が動いている領域（端末管理・ID管理・ISMS）だけ専門ロールにした。案件のない領域の専門家を先に作っても、中身のある指示が書けないからだ。

もうひとつの工夫は、PM だけはサブエージェントにせず、その会社のフォルダで起動したメインの会話そのものを PM にしたことだ。サブエージェントは別のサブエージェントを呼べない。各担当に仕事を振る役は、一段上にいる必要がある。

▼一番悩んだのは「混ぜない」設計

複数社の情報をAIに渡す以上、いちばん避けたいのはA社の情報がB社の作業に混ざることだ。ここに一番時間をかけた。

会社ごとにリポジトリを分ける

チーム全体の定義（ロールや事業の前提）を置く本体と、会社ごとの情報を置く場所を、物理的に別のリポジトリにした。どの会社のフォルダで起動したかで、見える情報が決まる構造だ。B社のフォルダで動いているAIは、そもそもA社の資料を持っていない。「混ぜるな」と指示するより、混ざりようがない構造にする方が確実だ。

共有するのは「匿名化した知見」だけ

一方で、1社で踏んだ地雷を別の会社でまた踏むのはもったいない。そこで、案件で得た知見は社名・人名・ドメイン・特定できる数字の組み合わせを消してから、領域別のノート（playbook）に追記するルールにした。「Intune の導入で、この順序にしたらフリーズの原因を切り分けられた」という知見は、会社名なしで別の会社の作業に使える。2か月分の案件から、25領域のノートができた。

原本は会社ごとに暗号化し、鍵も分ける

会議の文字起こしの原本には、口頭で伝えられた初期パスワードのようなものが混ざることがある。原本は会社ごとに暗号化したリポジトリに置き、鍵もパスワード管理ツールに会社ごとに保管した。契約が終わったら、その会社のリポジトリと鍵だけを消せるようにしておくためだ。

▼AIに「約束」させない

任せる範囲と同じくらい大事なのが、任せない範囲だ。このチームでは、次の操作はすべて下書き・準備までで止め、自分が確認してから実行する。

• ▶ メッセージの送信、先方への連絡
• ▶ 公開・投稿
• ▶ 購入・支払い
• ▶ データの削除
• ▶ 管理画面での設定変更

理由は単純で、責任を持つのは自分だからだ。期日や費用をAIが約束してしまえば、取り消すのは自分になる。

この方針は仕組みの作り方にも反映した。各社の Slack / Teams には読み取り専用で接続し、投稿やリアクションの機能は最初から登録していない。「使わないように指示する」のではなく、「使えないようにしておく」。情シスが社員の権限を設計するときと同じ考え方だ。チャットより見える範囲が広い SharePoint への接続は、チャットとは別に先方の承認を取り、給与・人事のフォルダは開かないルールを明記した。

▼会議メモ → 議事録 → タスクの流れを作った

このチームで一番効いたのは、会議の記録まわりだ。

打ち合わせでは、Zoom の「自分用メモ」機能で文字起こしを取っている。これを1日2回（13時・17時）自動で取得し、議事録係が次の流れで処理する。

文字起こしは人名や製品名の聞き間違いが多い。前提資料と照らして補正したものには「（推定）」、聞き取れないものには「※不明」と書かせている。わからないものを、もっともらしく埋めさせない。ここが肝だ。

過去2か月分のメモを流し込んだら、議事録は約70本になった。そして全部を読ませたことで、思わぬ効果があった。

「自分しか知らない状態」が可視化された

議事録を横断して読むと、会議ごとに食い違っている発言が浮き上がる。ある会社では、管理対象のスマートフォンの台数が、会議によって「20〜30台」「約40台」と揺れていた。どれが正しいかは、自分の頭の中にしかなかった。

こうした食い違いや未確定の点を、AIが会社ごとに「確認事項」として一覧にする。自分が知っていることは一問一答で答え、知らないことは「先方への確認リスト」に回す。2日目は、ほぼこの確認事項を潰す作業だった。結果として、6社分の「進行中の案件・次のアクション・期限」が、自分の頭の外に出た。

▼やってみてわかったこと

AIに作らせるより、AIが読める形で事実を残す方が効く

当初は「AIに作業を代わりにやってもらう」イメージだった。実際に効いたのは、作業そのものより事実を整理して残すことだ。前提資料が正確なら、返信の下書きもタスクの整理も精度が上がる。前提がずれていれば、どんなに賢いAIでもずれた答えを返す。

「実測」と「認識」のずれは、人もAIも同じ

情シスの現場では「そういう設定になっているはず」が、実測すると違うことがよくある。AIの前提資料も同じだ。議事録からの推測と実測値は分けて書かせ、実測には日付と取得元を必ず付けさせている。

「何が拾えないか」まで書いておく

定期的に動く仕組みは、止まると無音になる。Slack の新着を仕分ける仕組みは、新着があったときだけAIを呼び、至急のものは Mac の通知に出すようにした。PC を閉じている間は動かないことも含め、何が拾えて、何が拾えないかを手順書に書いておく。これを怠ると、仕組みがあることで逆に安心して見落とす。

▼これは「自分がいなくても回る」ための仕組みだ

情シスの仕事の軸は、「自分がいなくても回るものを作る」ことだと考えている。属人化した運用を手順と仕組みに落とし、誰が見てもわかる状態にする。

今回のチームは、それを自分自身の仕事に向けたものだ。会社ごとの前提資料、案件ごとの指示書、領域ごとの知見がテキストで残っていれば、AIだけでなく、将来いっしょに働く人にも引き継げる。

この考え方は、社内の情シスにもそのまま使える。「クライアント」を「部署」に、「契約」を「社内規程」に読み替えれば、構造は同じだ。ひとり情シスや兼任の担当者ほど、まず記憶の外部化から始める価値がある。

▼まとめ

• ▶ ロールは人のチームと同じ職務分掌で切る。専門ロールは案件がある領域だけ
• ▶ 会社（部署）ごとに情報を物理的に分け、共有するのは匿名化した知見だけ
• ▶ 送信・購入・削除・設定変更は下書きまで。使わせない機能は最初から渡さない
• ▶ 一番効くのは、会議の記録を「AIが読める事実」にして残すこと