Salesforceの未連携チェックを自動化した

Salesforceの未連携チェックを自動化した|CSV連携でハマった6つの罠

「朝にしかできない仕事」だった Salesforceに登録された作業実績が、別の仕組みに正しく連携されているか。連携に失敗したものが残っていないか。これを毎日確認する仕事があった。 厄介だったのは、この確認が朝にしかできなかったことだ。 データを集計するバッチ処理が夜間に走る。だから前日分の結果が出揃うのは朝。そして確認した内容は朝礼で共有する必要がある。つまり毎朝、出社してから朝礼までのあいだに、Salesforceを開いてレポートを出して、未連携のものを拾い出す——という作業が固定で入っていた。 自動化の価値は「時短」だけではなかった こういう話を書くとき、たいていは「作業時間が何分減りました」という数字を出すものだと思う。ただ、今回いちばん効いたのはそこではなかった。 朝のいちばん忙しい時間帯を、この作業のために空けておかなくてよくなった。 作業そのものの時間が長いわけではない。それでも「朝礼に間に合わせなければならない」という制約があると、その時間は他のことに使えない。別の急ぎが入れば焦るし、遅れれば朝礼に響く。時間の"長さ"ではなく"時間帯"を拘束されることの負担は、実際にやっている人にしか分かりにくい部分だと思う。 自動化してからは、朝礼の前にはもうTeamsに一覧が届いている。自分が何時に出社しようが関係ない。この安心感が、削減できた分数よりずっと大きかった。 同じように「たいした時間じゃないから」と我慢している作業がある人は、時間の長さではなく"いつやらなければいけないか"で見直してみるといいかもしれない。 作ったもの 構成はシンプルだ。 Salesforce のレポート(毎日 自動実行) ↓ CSVを添付したメールが届く Power Automate ├ メールを受け取る(差出人と添付で判定) ├ CSVを1行ずつの形に分解する ├ 連携に失敗している行だけを抜き出す ├ 必要な4項目だけを取り出す └ 表の形にしてTeamsに投稿 Salesforceにはレポートを定期実行して結果をメールで送る機能がある。まずこれで毎日CSVが自分宛に届くようにして、そのメールをPower Automateが受け取って処理する、という流れだ。 なぜCSVとメールなのか 見ての通り、かなり古典的なやり方だ。今どきシステム同士を繋ぐならもっとスマートな方法がある。それでもこうした理由は2つある。 ひとつは、Claudeから直接Salesforceを触ることが、この時点ではできなかったこと。以前に社内環境で「何ができて何ができないか」を調べたときの結論がそのまま効いている(詳しくはこの記事に書いた)。 もうひとつは、メール経由なら管理者に頼まずに自分で組めたこと。システム同士を直接つなぐ設定には管理者の権限が要る。一方「レポートをメールで受け取る」「届いたメールを処理する」だけなら、一般ユーザーの権限で完結する。 つまりこれは、制約の中で自分だけで完結させるための選択だった。理想の構成ではないが、動くものが今日できることのほうが大事だと判断した。 ハマった6つの罠 ここからが本題。Power Automateの式を書く部分で、想像の3倍くらい詰まった。同じところで止まる人が絶対にいると思うので、全部書いておく。 罠1:文字化けする 届いたCSVの中身が文字化けした。原因はSalesforce側のCSV出力がShift-JISという古い文字の形式になっていたこと。 解決:Salesforceのレポート設定でエンコードをUnicode(UTF-8)に変更した。処理する側で頑張るより、出す側を直したほうが早い。 罠2:CSVが1行の塊のまま分解できない CSVを行ごとに分けようとしたのに、全部がひと繋がりのまま出てくる。改行で区切っているつもりが区切られない。 原因は改行の正体がCR+LFという2文字の組み合わせだったこと。単純な改行文字で切ろうとしても一致しない。 解決:区切り文字を直接指定する形にした。 split(base64ToString(items('For_each')?['contentBytes']), decodeUriComponent('%0D%0A')) 呪文にしか見えないと思うが、意味が分からなくても問題ない。自分も細部は分かっていない。「CSVが1行にまとまってしまう」ときはこの形と覚えておけば足りる。 罠3:フィルターが全件を通してしまう 「連携に失敗した行だけ」を抜き出したいのに、全部の行が通ってしまう。条件が効いていない。 原因は、CSVの中の値が 0 ではなく "0" だったこと。前後にダブルクォートが付いていて、見た目は同じでも別物として扱われていた。 解決:比較する前にクォートを取り除く。 @and(greater(length(split(item(), ',')), 8), equals(trim(replace(split(item(), ',')[8], '"', '')), '0')) 「見た目は合っているのに一致しない」ときは、たいてい目に見えない何かが混ざっている。前にも列名に改行が紛れ込んでいて同じ目に遭った。この手の問題は本当に気づきにくい。 罠4:Teamsに「True」とだけ届く 通知が動いた。喜んで見たら、Teamsに投稿されていたのは True の1単語だった。 原因は、投稿する内容を選ぶところでメールのHTML本文のほうを間違って選んでいたこと。似た名前の項目が並んでいて、正しいものを選べていなかった。 解決:選択肢の検索欄で「テーブル」と検索して、目当ての出力を選び直した。Power Automateは選択肢が大量に並ぶので、目で探さず検索するのが確実だった。 ...

2026年8月15日 · 1 分
スキャンした書類の仕分けをAIに任せた

スキャンした書類の仕分けをAIに任せた|「格納しておいて」の一言で終わる仕組み

紙をスキャンした後に残る、地味な作業 複合機で紙の書類をスキャンする。これ自体は数秒で終わる。問題はそのあとだ。 出てきたPDFを開いて中身を確認し、書類番号と案件番号を読み取って、その番号でファイル名を付け直す。年月と案件ごとのフォルダを作って、そこに入れる。しかも一度にまとめてスキャンすると、1つのPDFの中に何件分もの書類が入っているので、それを1件ずつに切り分ける必要もある。 一件あたりは大した手間ではない。ただ、件数がまとまると地味に時間を取られるし、何よりファイル名を打ち間違えたり、入れる場所を間違えたりする。後から探せなくなるので、間違えると余計に面倒なことになる。 今はどうなっているか 先に結果を書くと、今はこうなっている。 「格納しておいて」と一言入力すると、全部終わる。 PDFを開いて中身を読み、番号を拾い、必要なら1件ずつに分割し、年月と案件番号のフォルダを作って、正しい名前を付けて格納する。おかしなデータがあれば処理せずに報告してくる。処理した履歴も残る。 チャットに打ち込む代わりにボタンを1つ押すだけでも起動できるし、時間を決めて勝手に走らせることもできる。 ただし、この「時間を決めて走らせる」には条件がある。動くのはパソコンが起動しているあいだだけだ。自分の環境では退社時にPCを停止するルールがあり、放置すると自動でシャットダウンもされるので、「夜のうちに走らせておく」ことはできない(この事情は46万件のファイル整理の記事で詳しく書いた)。 ちなみに同じ自動化でも、クラウド側で動くものは自分のPCが落ちていても動き続ける。以前に作った記入漏れの通知やSalesforceの未連携チェックはそちらなので、帰宅後も朝も勝手に動いている。「手元のPCで動くもの」と「クラウドで動くもの」の違いは、自動化を組むうえで意外と大事だった。 これまでの記事とは、AIの役割が違う このブログでこれまで書いてきた自動化は、どれもAIが相談相手だった。Power Automateの組み方を教えてもらったり、エラーの原因を一緒に探してもらったり。手を動かして仕組みを作るのは自分で、動かすのはPower Automateだった。 今回は違う。AIが処理そのものをやっている。 PDFを読んで「これは何番の書類か」を判断するのも、「この2つは別の書類だから切り分ける」と決めるのも、AIの担当だ。ここが今までと決定的に違うところで、正直やってみるまで「そんなことまでできるのか」と半信半疑だった。 仕組み:運搬・判断・確認を分ける とはいえ、AIに全部やらせているわけではない。実際の構成はこうなっている。 ① 複合機 → ネットワーク上のフォルダにスキャン(今まで通り) ② Power Automate Desktop ファイルを作業用フォルダへ運ぶ ③ Claude(黒子) 中身を読んで、名前を決めて、振り分ける ④ Power Automate Desktop 完成したものを所定の場所へ運ぶ ⑤ 人 中身を確認する 役割をひとことで言うと、運搬はPower Automate、判断はAI、最終確認は人。 なぜ分けたかというと、それぞれ得意なことが違うからだ。ファイルを決まった場所から決まった場所へ移すだけの作業は、Power Automateのほうが速いし確実で、しかもタダで動く。一方、中身を読んで判断する仕事はAIにしかできない。そして、間違いがあったときに責任を取れるのは人だけだ。 もうひとつ現実的な理由もある。AIが動いている場所からは、ネットワーク上の共有フォルダが見えなかった。この制約は以前に調べてあった(できたこと・できなかったことの記事に書いた通り)。だから「見える場所まで運んでくる」役をPower Automateに任せる必要があった。 制約から始まった分担だったが、結果的にこの形がいちばん理にかなっていたと思う。 AIにしかできなかったこと 具体的に、AIが担当している判断はこのあたりだ。 書類の中身を読んで番号を拾う 書類は手書きと印字が混ざっている。決まった位置に決まった文字があるわけではない。「この書類の番号はどれか」を読んで判断する必要がある。 何件分が入っているかを見分けて切り分ける まとめてスキャンした1つのPDFの中に、複数の書類が入っている。どこからどこまでが1件なのかは、中身を読まないと分からない。実際に39ページのPDFから7件の書類を切り出すところまで動いている。 おかしなものを見つけて止まる 作業した月と報告した月が食い違っているものは、処理せずに「これは変です」と報告してくる。機械的に処理していたら、間違った場所に入って後で分からなくなるやつだ。 一番の学びは「安全弁」の設計だった この仕組みを作る中で、一番勉強になったのは技術的なことではなく設計の考え方だった。 問題はこうだ。③のAIの処理が終わる前に、④の運搬が走ってしまったらどうなるか。まだ途中までしかできていないものが、完成品として所定の場所にコピーされてしまう。 これを防ぐために入れたのが完了マーカーだ。 AIは処理をすべて終えたとき、最後に「終わりました」という意味の空ファイルを1つ置く。④の運搬は、そのファイルがあるときしか動かない。無ければ何もせず、そのまま終了する。 仕組みとしては拍子抜けするほど単純だが、これがあるとないとでは安心感がまるで違う。自動化を複数つなげるときは、「前の工程が本当に終わったか」を次の工程が確認できる形にしておく——これは他の作業にもそのまま使える考え方だと思う。 ちなみにこの完了マーカーを置くルールは、AIの作業フォルダに置いた指示書に書いてある。毎回口頭で頼まなくても、そのフォルダで作業するときは自動的にそのルールが効く。 なぜ「全部自動」にしなかったのか 最後に人の確認を残しているのは、半分は制約、半分は意図的な選択だ。 制約というのは、AIを完全に自動で起動させることが今の環境ではできないこと。だから「運搬を動かす → AIに一声かける → 完成したら運搬を動かす」という半自動の形になっている。 ただ、仮に全部つながったとしても、最後の確認は人が残すと思う。読み取った番号が1文字違っていても、機械は気づかない。確認する場所を1か所だけ残しておけば、そこで全部止められる。 自動化というと「人の手を完全に無くすこと」だと思われがちだけど、実際に作ってみて感じたのは、人が見る場所を1か所に絞ることのほうが価値があるということだった。以前は全部の工程で気を張っていたのが、今は最後の確認だけになった。減ったのは作業時間だけでなく、気を配る対象の数でもある。 「アーティファクト」の使い道がやっと分かった ここで、ずっと持て余していた機能の話をしたい。 ...

2026年8月15日 · 1 分
ClaudeとCopilotを非エンジニアが使い比べた

ClaudeとCopilotを非エンジニアが使い比べた|Power Automateで自動化して分かった差

※この記事の「Copilot」について ここで比較しているのは、Officeなどの中にいるアシスタントとしての Microsoft Copilot です。2026年6月に一般提供が始まった Copilot Cowork(時間のかかる作業をまるごと任せられる仕組み)とは別の製品です。 そちらをお探しの方は、Copilot CoworkとClaude Coworkの違いのほうをご覧ください。 会社にはClaudeもCopilotもある 毎日、SharePoint上の台帳を開いて、記入漏れがある行を探して、担当者に声をかける。地味だが誰かがやらないと後で困る、そういう仕事があった。 これを自動化しようと考えた。決まった時刻に台帳をチェックして、未入力があればTeamsに通知が飛ぶようにする。 最初は、Claudeに直接やらせるつもりでいた。ところがこれができない。SharePoint上にあるExcelは、Claudeからは直接読めなかったからだ。手元にコピーすれば読めるのだが、それを毎日手でやるなら自動化の意味がない。 (この「どこに置いてあるファイルなら読めるのか」は最初に調べてあった。詳しくは前回の記事に書いている) そこで方針を変えた。**ファイルを触る部分はMicrosoft Power Automateにやらせる。**AIにできないことは、別のツールに任せればいい。 ただ、こちらはプログラミングの経験がない。Power Automateも初めて触る。となると、誰かに聞きながら進めることになる。 幸い、会社にはAIが2つある。Microsoft CopilotとClaudeだ。せっかくなので両方に相談しながら作ってみた。この記事は、そのとき何が違ったかの記録になる。 先に断っておくと、これは「自分がこの作業をやったときの話」であって、どちらが優れているという一般論ではない。実際、後半に書くようにCopilotのほうが向いている場面もある。 作ったもの まず何を作ったのかを簡単に。 毎日決まった時刻に、SharePoint上にある当月の台帳(Excel)を自動で開く 記入漏れの行を抽出する(案件番号はあるのに、記入者の欄が空、または「未確認」のままのもの) 対象外の取引先は除外する 該当があれば、Teamsに一覧を投稿する。ゼロ件なら何も送らない 文章にすると4行だが、これを作るのに何日かかかっている。理由は後述するが、途中で「これは無理かもしれない」と思う場面が何度かあった。 つまずいた場所:見えない文字が入っていた 一番苦労したのは、フィルターがどうしても効かないことだった。 台帳から「記入者の欄が空の行」を取り出そうとすると、結果がゼロ件になる。実際には空の行がいくつもあるのに、だ。設定を見直しても、書き方を変えても、うまくいかない。 原因が分かったときは脱力した。Excelの列名(見出し)の中に、改行文字が紛れ込んでいたのだ。 見た目には分からない。セルを見ても普通の見出しにしか見えない。ところがプログラムから見ると、その列の名前は「記入者」ではなく「記入者+改行」という別物になっていて、だから「記入者という名前の列」を探しても見つからなかった、という話だった。 これは非エンジニアには絶対に思いつかない類の原因だ。「自分の書き方が間違っている」としか思えないし、実際そう思って何時間も設定をいじっていた。 最終的には、列名を指定する代わりにデータ全体を文字列として検索する方法で回避した。正攻法ではないが動く。 ここで差が出た①:曖昧な質問に答えられるか この「原因不明で詰まっている」状態こそが、2つのAIの差がはっきり出た場面だった。 こちらが投げられる質問は、正確には程遠い。 「フィルターが効かない。空の行があるはずなのに0件になる。なんで?」 専門用語で症状を説明できないから、こういう聞き方になる。何が起きているか分かっていないのだから当然だ。 Copilotは、この手の質問で意図を取り違えることがあった。 一般的な設定手順の説明が返ってきたり、こちらが既に試したことをもう一度勧められたりする。そして何より、やり取りが続くと前の話を見失う。「さっき言った条件で」が通じなくなると、また最初から説明することになる。原因究明は往復回数が多くなるので、これは地味に効いた。 Claudeは、曖昧なまま投げても文脈を保ったまま付き合ってくれた。 「その症状なら、列名に見えない文字が入っている可能性がある」といった、こちらが思いつかない仮説を出してくる。しかも「じゃあどう確認するか」まで具体的な手順で示してくれる。 改行文字の件も、自力では絶対にたどり着けなかった。「素人の曖昧な訴えから、原因の候補を出す」——非エンジニアが一番助けてほしいのは、まさにここだと思う。 ここで差が出た②:画面を見せて聞けるか もうひとつ、そして個人的にはこちらのほうが決定的だった差がある。スクリーンショットを見せて聞けるかどうかだ。 Power Automateのような専門ツールは、画面の各部分に名前がある。でも初めて触る人間はその名前を知らない。だから言葉で説明できない。 「右上の……なんか歯車みたいなやつの下に出てくる、青い文字の部分」 こんな説明で伝わるはずがない。だから画面を撮って「これのどこを押せばいい?」と貼るのが一番早い。 ここでの差は大きかった。Copilotは画面の状況をうまく把握できないことがあり、貼った画像とかみ合わない回答が返ってくることがあった。Claudeは画面を読み取って、「その画面なら、左側の◯◯を開いて、△△を選ぶ」と具体的に案内してくれた。 言葉を知らなくても質問できる、というのは非エンジニアにとって想像以上に大きい。用語を調べる時間がまるごと消えるからだ。 違いは「道筋が見えているかどうか」 ここまで読むとClaude一択に見えるかもしれないが、そうではない。両方を使ってみて、自分なりに整理できた軸がある。 Claudeが効くのは、ゴールは決まっているのに道筋が分からないとき。 今回がまさにそれだった。「記入漏れを自動で知らせたい」というゴールははっきりしている。でも、そこへどう辿り着けばいいのかは何も分かっていない。フィルターが効かない理由も分からない。こういう状態で、こちらが理解していないことまで推論して「たぶんこれが原因では」と提案してくれるのがClaudeの強みだった。 Copilotが効くのは、道筋が分かっているとき。 Officeの中に常駐していて、作業している横で逐一手を貸してくれる。やることが決まっている作業を速くする、加速装置のような存在だ。 Officeの中で完結する作業:Excel、Word、Teamsの画面からそのまま呼び出せる。別の窓を開いて往復しなくていい 社内の情報を踏まえた作業:会議の要約、これまでのやり取りを前提にした下書き 短い定型作業:メールの下書き、文章の整え——わざわざ相談するまでもないもの つまり、Claudeは「道筋を一緒に探す相手」、Copilotは「決まった道を速く進むための装置」。優劣ではなく、そもそも役割が違う。加速装置は、既に動いている人を速くすることはできるが、止まっている人を動かすことはできない。 そう考えると、時間軸での使い分けも見えてくる。分からないうちはClaudeに相談して道筋を決め、やることが固まったらCopilotで手を動かす。 自分の中では、この流れが自然になりつつある。 結果として、どうなったか 出来上がったフローは本番で動いている。 決まった時刻に台帳を読んで、記入漏れがあればTeamsに一覧が届く。手作業で確認していた時間はゼロになった。抽出の正確さも、手で数えた結果と一致することを何度か確認している。 ...

2026年8月11日 · 1 分
Claude Coworkでできたこと・できなかったこと

Claude Coworkでできたこと・できなかったこと|社内導入で最初にやった動作確認

派手なことをやる前に、地味な確認をした 会社でClaudeのトライアルが始まって、最初に手をつけたのは業務の自動化ではなかった。ひたすら地味な動作確認だった。 どのフォルダなら読めるのか。Excelは開けるのか。作ったファイルはどこに置けるのか。チャットの履歴は取ってこられるのか。ひとつずつ試して、結果を書き留めていく作業に丸一日使っている。 なぜ最初にこれをやったかというと、AI活用の記事をいくら読んでも、自分の会社の環境で同じことができるとは限らないからだ。会社にはそれぞれのファイル置き場があり、セキュリティの設定があり、契約している範囲がある。記事の通りにやってみて「うちの環境ではできませんでした」が何度も続くと、たいてい心が折れる。 だから先に地図を作ることにした。結果的に、これが一番効いた。以降に作った自動化は全部、このときの調査結果を前提に設計している。 この記事では、そのとき分かったことをそのまま公開する。同じように社内でAIを触り始めた人が、遠回りせずに済めばいいと思っている。 大前提:Coworkは「PCの中の別の小部屋」で動いている 個別の話に入る前に、ひとつだけ理解しておくと全部が繋がる前提がある。 Claude Coworkは、パソコンの中に用意された隔離された作業スペースの中で動いている。技術的にはLinuxのサンドボックスと呼ばれるものだが、イメージとしては「自分のPCの中に、もう一つ小さな部屋がある」と思えばいい。 この小部屋は、外の世界から切り離されている。だから何でも勝手に触られる心配がない代わりに、こちらが「この棚は見ていいよ」と許可したものしか手が届かない。 これを分かっていないうちは、「できる/できない」が脈絡のない豆知識の羅列に見えてしまう。逆に分かってしまえば、ほとんどの制約は「その小部屋から手が届く範囲か」で説明がつくようになる。 できたこと 自分の環境で実際に動いたのは、次のような操作だった。 やりたいこと 結果 補足 指定した作業フォルダの読み書き ✅ ローカルもOneDriveも可。複数のフォルダを指定できる Excelファイルの読み取り・加工・保存 ✅ 手元に保存されているファイルであれば可 PDF・Word・Excel・PowerPointの作成 ✅ 日本語フォントも書式もそのまま反映された Teamsの個人チャット・グループチャットの検索と閲覧 ✅ 過去のやり取りを探してもらえる Box上のテキスト系ファイルの読み書き ✅ Boxへのアップロードもできた ウェブ検索 ✅ — ファイル作成については、想像していたより出来がよかった。表の罫線、セルの色、列幅、文字色まで指定通りに反映される。報告書のドラフトを作らせて、そのまま体裁を整えた状態で出してもらえるレベルだ。 このとき意識してやったのは、「何を使って作られたか」まで記録に残すことだった。PDFはweasyprint、Wordはpython-docx、Excelはopenpyxl、PowerPointはpython-pptx——ここまで書いておくと、次に同じことをやるときに調べ直さずに済む。地味だが後々かなり効いた。 この横文字はAIが裏側で使っている道具の名前で、意味が分からなくても全く問題ない。自分も中身は分かっていない。「こういう名前を控えておくと後がラクになる」とだけ知っていれば十分だ。 できなかったこと 一方で、はっきり無理だったものもある。 やりたいこと 結果 理由・状況 指定していないローカルフォルダを読む ❌ そういう仕様。安全のための制限 ネットワーク共有フォルダを直接指定する ❌ ただし回避策あり(後述) Excelのマクロ(VBA)を動かす ❌ 小部屋の中にExcelそのものが無いため SharePoint上のExcelを直接読む ❌ 手元にコピーすれば読める SharePointへのファイルのアップロード ❌ 読み取り専用の扱いだった Teamsのチャンネル投稿を取得する ❌ 接続設定の権限による。管理側に要望中 ブラウザ(Chrome)を自動で操作する ❌ 「Claude in Chrome」の導入待ち。実装されれば解決する見込み このうち「マクロが動かない」は、言われてみれば当然なのだが最初は驚いた。小部屋の中にはExcelというソフト自体が入っていないので、ファイルの中身は読めても、Excelの機能を使う処理は動かせない。ファイルを「データとして」扱うのと、「Excelで開く」のは別物だということだ。 一番ハマったのは「見えているのに見えない」問題 調査の中で一番わかりにくく、原因究明に時間を取られたのがこれだった。 同じファイルなのに、どうやってアクセスするかによって、見えたり見えなかったりする。 ...

2026年8月6日 · 1 分
社内のClaudeに「黒子」と名付けた

社内のClaudeに「黒子」と名付けた|非エンジニアがAIと働き始めた話

会社に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との比較も実際にやっていて、その違いは記事にする価値があると思っている。 → 詳しくはこちら:ClaudeとCopilotを非エンジニアが使い比べた|Power Automateで自動化して分かった差 ③ 共有フォルダの約46万件を安全に整理する仕組み 長年の蓄積で膨れ上がった共有フォルダの整理。ポイントは「AIに全部を読ませない」ことだった。この規模を素直にAIに渡すとコストが跳ね上がるので、機械的に処理できる部分は別の方法で削ってから渡す設計にした。 → 詳しくはこちら:共有フォルダの46万件を整理する|AIに「全部読ませない」ための設計 ④ 「確証格納して」の一言で終わる仕組み スキャンしたPDFを、中身を読んで名前を付け替え、決まったフォルダに振り分ける作業。39ページのPDFから7件の書類を自動で切り出す、といったこともやっている。今では一言指示するかボタンを押すだけで完結する。ここではPower Automate Desktopと組み合わせていて、ファイルの運搬はPower Automate、中身の判断はAI、最終確認は人という役割分担にしている。この分け方は他の業務にもそのまま応用が効いた。 ...

2026年8月6日 · 1 分