ブログ運営

会社にAIが来た。でも自分に使えるのか？ある日、会社でClaudeのトライアルが始まった。正直なところ、最初に思ったのは「自分に関係あるのだろうか」だった。AIで業務効率化、という言葉はよく聞く。ただ、そういう話に出てくるのは決まってエンジニアの人たちで、コードを書いて、システムを組んで、という世界の話に見えていた。こちらはプログラミングの経験がない。Excelの関数はそれなりに使うけれど、それ以上のことはやったことがない。そんな人間にAIを渡されても、結局「文章を少し整えてもらう」くらいで終わってしまうのではないか。そう思っていた。結論から言うと、その予想は外れた。数ヶ月のあいだに、共有フォルダに眠っていた約46万件のファイルを整理する仕組みを作り、紙の報告書をスキャンしたPDFを自動で仕分けする処理を組み、毎日手で確認していた記入漏れのチェックを自動通知に置き換えた。どれも、これまでの自分なら「システム部門に依頼するしかない」と諦めていた類の作業だ。このブログは、その過程で分かったこと・つまずいたことを、非エンジニアの視点から記録していく場所にしたいと思っている。社内のClaudeを「黒子」と名付けたまず名前の話から始めたい。というのも、これがこのブログの立ち位置そのものを表しているからだ。会社で使っているClaudeには「黒子（くろこ）」という名前を付けた。舞台の黒子——役者の後ろで小道具を渡したり、衣装を替えたりする、あの黒い装束の裏方だ。観客からは見えないことになっているけれど、いなければ芝居は回らない。 AIに求めていた役割が、まさにそれだった。表に立って何かを判断してくれる存在ではなく、こちらが判断するための下ごしらえを黙々とやってくれる相棒。名前を決めるとき、真っ先に浮かんだのがこのイメージだった。ちなみに個人で使っているClaudeのことは、前から「クロコ」と呼んでいる。Claude Code、Claude Cowork の頭文字を取ったものだ。音が同じで表記だけ違うのは意図的で、「同じ相棒だけれど、立っている場所が違う」という区別のつもりでいる。名前を付けると、扱いが変わるこれは完全に個人的な感覚の話なのだけれど、名前を付けてから明らかに使い方が変わった。「AIツール」と呼んでいるあいだは、どうしても検索エンジンの延長で見てしまう。質問を投げて、答えが返ってきて、それで終わり。けれど「黒子」という名前で呼ぶようになってから、こちらの頼み方が変わった。前提を先に共有するようになったし、失敗したときも「なぜ伝わらなかったか」を考えるようになった。人に仕事を頼むときの感覚に近い。道具に名前を付けるなんて、と思う人もいるかもしれない。ただ、AIを業務で使うときに一番効くのは、実はこの「頼み方」の部分だったりする。その話はまた別の記事で書きたい。個人環境は「設計室」、社内環境は「実行エンジン」もうひとつ、最初に決めておいてよかったルールがある。社内のClaudeは従量課金の環境で動いている。つまり、やり取りをすればするほどコストがかかる。自分は情報システム部門の人間ではないので、会社のお金を使っている以上、無駄な使い方はしたくないという意識が最初からあった。そこで役割を分けることにした。個人環境＝設計室：どう作るか迷っている段階、試行錯誤、原因の切り分けはこちらでやる社内環境（黒子）＝実行エンジン：やることが固まったタスクだけを、完成した指示として渡す「何をどうしたいのか」がぼんやりしたまま社内環境に持ち込むと、確認のやり取りが往復するぶんだけコストが積み上がる。逆に、手順が固まった状態で渡せば一発で終わる。この切り分けを最初に決めたおかげで、コストを気にせず実験できる場所と、本番データを扱う場所の両方を確保できた。従量課金でAIを導入した会社にいる人には、この考え方はけっこう役に立つのではないかと思っている。個人契約と会社の環境は、別物だと思ったほうがいいここまで「個人環境」「社内環境」と書き分けてきたが、この2つは料金の払い方が違うだけではない。データの扱いそのものが違う。同じことをやってみようという人に一番気をつけてほしい部分なので、少しだけ詳しく書いておきたい。個人で契約しているプランは定額制で、どれだけ使っても月額は変わらない。一方、会社の環境はAmazon Bedrock経由の従量課金なので、やり取りした量に応じて費用がかかる。前の章で環境を分けた理由はこれだ。ただ、本題はここではない。重要なのはデータの扱いのほうだ。個人向けのプランでは、自分の会話をAIの改善（モデルの学習）に使ってよいかどうかを、利用者自身が設定で選ぶ形になっている。許可すればその会話は将来の学習に使われ、データの保存期間も長くなる。許可しなければ以降の学習には使われず、保存期間も短くなる。どちらを選ぶかは自由だが、そういう設定項目があること自体を知らないまま使っている人は少なくないと思う。対して、会社で使っているBedrock経由の環境は構造が違う。AWSの公式ドキュメントには、モデルの提供元（この場合Anthropic）はBedrockのログや利用者のプロンプト・応答にアクセスできない仕組みになっている、と明記されている。こちらが入力した業務データが提供元に渡って学習に使われる、ということが起きない構造だ。会社の情報を扱ううえで、この違いは大きい。ひとつ補足しておくと、これはBedrockだけの特長ではない。API経由の利用や法人向けプランでも、既定では会話が学習に使われない扱いになっている。分かれ目は「個人向けプランかどうか」だと考えたほうが正確だ。そのうえで、このブログの内容を試してみようという人には、先に確認してほしいことがある。自分が今触っているのは個人契約か、会社が用意した環境か会社の環境なら、どういう形態で提供されているのか個人契約なら、学習利用の設定が今どうなっているかそして何より、自分の会社の情報取扱いルールで何が許可されているか最後の項目が一番大事だ。仕組みとして安全であることと、社内で許可されていることは別の話で、それを決めるのは自分ではない。自分の場合も、業務データを扱う前に社内のルールを確認したうえで進めている。少しでも迷うなら、自己判断せず情報システム部門に聞いたほうがいい。個人の判断で会社の情報を外部サービスに入れて問題になったとき、失うものが大きすぎる。 ※ここに書いた内容は2026年8月時点で公開情報を確認したもの。規約や仕様は変わるので、実際に判断するときは必ず最新の公式情報を確認してほしい。参考：Anthropic プライバシーセンター／Amazon Bedrock のデータ保護これまでにやったこと具体的に何をしてきたのか、ダイジェストで挙げておきたい。それぞれ後日、個別の記事にしていく予定だ。 ① 社内環境で「できること・できないこと」の洗い出し最初にやったのは、地味だが徹底的な動作確認だった。どのフォルダが読めてどこが読めないのか、Excelは扱えるのか、ファイルは作れるのか。AI活用の記事はたくさんあるけれど、会社の環境には会社ごとの制約がある。そこを把握しないまま進めても、途中で必ず行き詰まる。 → 詳しくはこちら：Claude Coworkでできたこと・できなかったこと｜社内導入で最初にやった動作確認 ② 記入漏れの督促を自動通知に置き換えた毎日、台帳を開いて未記入の行を探して、担当者に声をかける。この作業をMicrosoft Power Automateで自動化した。決まった時刻に台帳をチェックして、未入力があればチャットに通知が飛ぶ。フローを組んだのは自分だが、設計と、詰まったときの原因究明はClaudeに付き合ってもらった。ここではMicrosoft Copilotとの比較も実際にやっていて、その違いは記事にする価値があると思っている。 ③ 共有フォルダの約46万件を安全に整理する仕組み長年の蓄積で膨れ上がった共有フォルダの整理。ポイントは「AIに全部を読ませない」ことだった。この規模を素直にAIに渡すとコストが跳ね上がるので、機械的に処理できる部分は別の方法で削ってから渡す設計にした。 ④ 「確証格納して」の一言で終わる仕組みスキャンしたPDFを、中身を読んで名前を付け替え、決まったフォルダに振り分ける作業。39ページのPDFから7件の報告書を自動で切り出す、といったこともやっている。今では一言指示するかボタンを押すだけで完結する。ここではPower Automate Desktopと組み合わせていて、ファイルの運搬はPower Automate、中身の判断はAI、最終確認は人という役割分担にしている。この分け方は他の業務にもそのまま応用が効いた。 ⑤ 月次の照合作業をまるごと自動化 ...