Coworkが無くなった。気づかなかった

Coworkが無くなった。気づかなかった|機能の名前は変わる、頼み方は残る

軸にしていたものが、消えるらしい 2026年9月16日、AnthropicがClaude Coworkとチャットを統合すると発表した。1つの画面にまとまり、Coworkという名前は、いずれ消えるとされている。 これを知って、正直まずいと思った。 このブログは、Coworkの話で11本書いてきたからだ。できたこと・できなかったことの記事はタイトルからしてそうだし、Copilotとの比較も、その名前を前提に書いている。 軸にしていた言葉が無くなる。書き直しか、と身構えた。 ところが、気づいていなかった 自分のパソコンには、すでに統合版が来ていた。 気づいたのは、週に一度まとめているニュースを読んだときだ。ニュースで知るまで、自分の画面が変わっていたことに気づいていなかった。 しかも普段はスマートフォンから使うことのほうが多い。つまりパソコンでもスマホでも使っていて、両方とも気づかなかったということになる。 11本書いてきた当人が、である。 なぜ気づかなかったのか 考えてみて、理由はひとつしか思い当たらなかった。 頼み方が、何も変わっていなかったからだ。 前と同じように「これをやっておいて」と日本語で書いて、あとは任せる。返ってきたものを見て、直してもらう。その行為が1ミリも変わらなかったので、入れ物の名前が変わったことに気づきようがなかった。 ここで、自分の思い込みがひとつ壊れた。 自分が使っていたのは「Coworkという機能」ではなかった。「Claudeに仕事を任せる」という行為のほうだった。 機能の名前は、その行為を入れておく箱にすぎなかった。箱が別のものに替わっても、中身が同じなら、使っている側は気づかない。 AIへの頼み方をまとめた記事に、こう書いた。 同じことを二度説明したら、それは文書にすべきサイン あのとき書いたのは頼み方の話で、機能の話ではなかった。だから今回の変更で、1行も古くならなかった。 非エンジニアがAIの新機能に対して一番感じる不安は、たぶん「また覚え直すのか」だと思う。今回それを実地で確かめた形になった。 機能の名前は変わる。頼み方は残る。 覚えるなら、後者のほうが長持ちする。 何が変わって、何が変わらなかったか 公式の説明と、実際に使ってみた感触を並べるとこうなる。 内容 変わったこと チャットと作業依頼が1つの画面に統合。「どちらで頼むか」を選ばなくてよくなった Claudeが内容を見て、すぐ答えるか、裏で長めに作業するかを自分で判断する 全体の指示を書く場所が「設定 › 一般」へ移動 文書を書くClaude Docs、スライドを作るClaude Slidesがベータで追加 変わらなかったこと これまでの会話・成果物・外部サービスとの連携・登録した手順は、そのまま引き継がれる 頼み方 いちばん大きい変更は「どちらで頼むかを選ばなくてよくなった」だと思う。ただ、自分の場合はそもそも迷っていなかった。重い作業を投げるときも、軽く聞くときも、同じ調子で書いていたからだ。 だから、選択肢が消えたことにも気づかなかった。 ⚠️ ひとつだけ、気づかないと損する変化がある ここまで「気づかなくて大丈夫だった」という話をしてきたが、1つだけ例外がある。 使える量の枠が、ひとつにまとまった。 これまでは感覚として「重い作業」と「軽い質問」が別勘定のように思えていた。これからは同じ枠から引かれる。長い作業は、普通の質問より多く消費するとも明記されている。 正直に書くと、自分はまだこれを実感していない。急に上限に当たった、といった経験はない。 ただ、理屈の上ではこういうことが起きうる。 パソコンで重い作業をさせる ↓ 同じ枠から引かれる スマホで普段どおり質問したら「上限です」 食う側と、困る側で、端末が違う。 しかも時間もずれる。これは原因にたどり着きにくいと思う。知らなければ「アプリが壊れた?」で終わってしまう。 今回のことで、変化には2種類あるのだと整理できた。 例 どうすればいいか 気づかなくていい変化 画面の統合、名前が消えること 追いかけなくていい。現に気づかずに使えていた 気づかないと困る変化 使える量の枠がひとつになった これだけは知っておく 新機能の発表があるたび全部を追いかけるのは、正直しんどい。追わなくていいものと、これだけは見ておくものを分ける。今回の学びはここだった。 会社の環境には、まだ来ていない もう1つ、書いておきたいことがある。 ...

2026年9月20日 · 1 分
AIに書類チェックを任せてみた

AIに書類チェックを任せてみた|信用できるかは「分からない」と言えるかで決まった

「Claudeで作れないか」と言われた 上司から相談があった。書類のチェックを自動化できないか、という話だ。 前提として、すでに似た仕組みは動いていた。書類を共有フォルダにアップロードするとき、その場でCopilotに読ませて、決まった観点でチェックする——という運用だ。1件ずつなら、これで足りている。 問題はすでにアップロードされた分だった。Copilotからは共有フォルダの中のファイルに手が届かない。つまり「入口」は見張れても、すでに積まれたものをまとめて確認する手段がなかった。 そこを埋められないか、というのが相談の中身だった。 作ったもの 構成は素っ気ないくらい単純だ。 8:50 / 17:50 PowerShell ↓ 新しく増えたフォルダを検出して、一覧をファイルに書き出す 9:00 / 18:00 Claude(スケジュール実行) ↓ その一覧を読んで、PDFをチェック ↓ 結果をまとめて共有フォルダに出力 ↓ 処理済みとして記録 1日2回、誰も操作しない。 朝出社したら、前日分のチェックが終わっている。 なぜこの形になったのか、2つだけ書いておく。 ① 一度に全部やらせたら、途中で止まった 最初は素直に「フォルダの中を全部見て」と頼んだ。途中でタイムアウトして止まった。 考えてみれば当然で、対象は月に1000件近くまで増えていく。しかも毎日増え続けるので、放っておけば量は膨らむ一方だ。一度で終わらせようとする限り、いつか必ず破綻する。 そこで方針を変えた。すでに処理したフォルダを記録しておいて、前回から増えた分だけを渡す。 その「増えた分を見つける係」をPowerShellに任せている。 これで止まらなくなったし、読ませる量が減るので費用も下がる。46万件のファイルを整理したときにも同じ結論に辿り着いていた。 止まることを前提に作る。一度で終わらせようとしない。 別の業務で、また同じ教訓を踏んだことになる。大量のものを扱うときは、たぶんこれが唯一の正解なのだと思う。 なお読ませるのも原則1ページ目だけにしている。必要な情報はそこにしかないからだ。 ② 直接つながらないので、ファイルでバトンを渡す PowerShellとClaudeのスケジュール実行は、互いを呼び出せない。そこで10分ずらして動かし、あいだをファイル1つで繋いだ。8:50に一覧が書き出され、9:00にそれを読む。 書類の仕分けを作ったときも、完了の合図をファイルで渡していた。直接つながらないものを、ファイル1つで安全につなぐ——同じ手を2回使ったことになる。地味だが、これが一番壊れにくい。 いきなり、人の見落としを見つけた テスト段階で、予想していなかったことが起きた。 すでに人の目を通っていた書類から、チェック漏れが見つかった。 レ点を入れるべき欄が空欄のまま、というものだ。 考えてみると当然かもしれない。人は書類を読むとき、「ここにはレ点があるはずだ」と無意識に補ってしまう。何十枚も見ていればなおさらだ。機械はそれをしない。 空欄は空欄として見る。 ここで感じたのは、人の代わりをさせているのではないということだった。人が得意なところと、機械が得意なところは違う。今回埋まったのは、人がどうしても苦手な種類の見落としだった。 でも、いちばん安心したのは別のところ 成果としては上の話が分かりやすい。ただ、実際に使っていて安心したのは違う点だった。 判断が付かないものについて、勝手に決めずに聞いてくる。 これは意図してそう設計した。チェックのルールに、こう書いてある。 判断が付かない項目、および書類にその項目自体が存在しない場合は、推論せずに確認すること。 なぜこうしたか。**検査という仕事で怖いのは、間違えることより「間違えたことに気づけないこと」**だからだ。 もしAIが「たぶん問題ないでしょう」と埋めてしまったら、こちらはそれを信じる。逆に「たぶん不備です」と言われて、それが的外れなら、確認の手間が増えて信用を失う。どちらも困る。 分からないものを分からないと言ってくれるなら、残りは信じられる。 信頼性というのは正確さの話だと思っていたけれど、実際に使ってみると**「言わないことを決められるか」**のほうが効いた。 これは以前46万件のファイルを仕分けたときに決めたルールと同じ構造だった。 迷ったら全部「要確認」に入れる。AIに「たぶん消していいと思います」と判断させない。 別の業務で、同じ原則がまた効いた。たぶんこれは、AIに判断を任せるときの一般的な作法なのだと思う。 最初は、盛大に誤検出した もっとも、最初からうまくいったわけではない。 初期に多かったのが「存在しない項目を不備として報告してくる」というものだった。書類にはいくつか種類があって、種類によってある項目とない項目が違う。それを知らないまま「この項目が空欄です」と指摘してくる。 これはAIが賢くないのではなく、こちらが伝えていなかっただけだ。何ができて何ができないかは最初に一通り調べてあったけれど、業務のルールは調べても出てこない。自分で伝えるしかない部分だった。 だからルールを書き足した。 書類に存在する項目のみをチェック対象とすること。 これで解消した。AIへの頼み方をまとめた記事に「同じことを二度説明したら、それは文書にすべきサイン」と書いたけれど、まさにその通りだった。誤検出が出たら、まず自分の指示を疑う。 「作って終わり」ではなく、育てる期間がある 正直に書いておくと、この仕組みはまだ完成していない。 チェックすべきパターンが多く、新しい書式が出てくるたびにルールを足していく必要がある。当面は、出てきた誤検出を見ながら人が教え続けることになる。 これは面倒に聞こえるかもしれないが、人に仕事を引き継ぐときも同じだと思う。最初から完璧に引き継げる仕事はない。何度か一緒にやって、例外を伝えて、だんだん任せられるようになる。相手がAIでも変わらなかった。 そして——誰も見ていない ここまで書いておいて、いちばん大事なことを書く。 ...

2026年9月9日 · 1 分
アーティファクトでBoxの管理画面を作った

アーティファクトでBoxの管理画面を作った|チャットでは動くのに、中では動かないもの

アーティファクトの使い道が、また一段広がった 以前、書類の仕分けを自動化した記事で、Claudeの「アーティファクト」という機能の使い道について書いた。要約するとこうだ。 繰り返しやっている作業のボタンを1つ作ってみる。アーティファクトは、AIへの指示を「アプリの操作」に変換する道具として使える。 今回はその続きになる。ボタン1つではなく、画面の横に出しっぱなしにしておく管理画面を作ってみた。 きっかけは、社内のClaudeにBoxとつながる機能(コネクタ)が入ったことだった。 作ったもの 2つ作った。 ① ファイル一覧・更新監視の画面 Boxのフォルダをブラウザ上で開いて、中身を見られるようにしたもの。 フォルダをクリックして階層を掘り下げられる(パンくず表示つき) ファイル名・サイズ・更新日時を一覧表示、列見出しをクリックで並べ替え 名前で絞り込み検索 前回見たときからの差分を検出して、更新・新規のファイルに色を付ける ② Box AIで一括分析する画面(本命だった) こちらは少し説明が要る。Box AIというのは、Box自身が持っているAI機能のことだ。Claudeとは別物で、Boxに置いてあるファイルをBoxの中で読んで答えてくれる。 なぜそれを使いたかったかというと、ファイルの中身をClaudeに送らなくて済むからだ。社内のClaudeは使った分だけ費用がかかるので、大量のファイルをそのまま読ませると高くつく。Box AIに読ませて要約だけ受け取れば、こちら側の負担はぐっと減る。46万件のファイルを整理したときに学んだ「必要な分だけ読ませる」の応用でもある。 作ったのは、フォルダ内のファイルに対してまとめてBox AIに指示を出す画面。「要点を抽出して」「リスクがありそうな箇所を挙げて」といった指示を自由に書いて、結果を一覧で見る——そんなものを想定していた。 契約書の要点抽出や、議事録からのアクション整理に使えるはずだった。 ところが、本命が動かなかった ②を動かしてみたら、すべてのファイルでエラーになった。Access denied——アクセスが拒否された、という意味だ。 調べていくと、原因は権限の設定だった。少し細かい話になるが、大事なところなので書いておく。 Box AIを外部のアプリから呼び出すには、2段階の許可が必要だった。 会社としてBox AIを有効にする → これは有効になっていた(Boxの画面から直接使えたので) アプリごとにBox AIの利用を許可する → こちらが未設定だった つまり「自分はBoxの画面からBox AIを使えるが、Claudeという"アプリ"にはBox AIを使う許可が下りていない」という状態だった。 ここで時間を使ったのは、最初にフォルダの閲覧権限を疑っていたことだ。ファイル名や更新日時は取れているのだから権限はあるはずなのに、と混乱した。切り分けの決め手になったのは「Boxの画面から手で操作すると成功する」という事実で、そこから「人ではなくアプリの側の権限だ」とたどり着いた。 そして、この権限はたぶん下りない 原因が分かったので、管理者への依頼文書を作った。ここまではSalesforceの設定を依頼したときと同じ流れだ。 ただ、今回は事情が違った。 この設定は、契約全体に対して有効になる。 外部アプリへの許可は、利用者ごとや部署ごとに切り分けられない。つまり依頼を受ける側から見ると、 「この会社(あるいはグループ全体)で、この外部アプリにBox AIを使わせてよいか」 という判断になる。こちらの感覚では「試しに使ってみたいだけ」でも、受け取る側にとっては全社の話なのだ。 そう考えると、一人の試用のために全体の設定を変えてもらうのは、筋として重い。通らない可能性のほうが高いと考えたほうが自然だと思った。 だから「使えないまま運用する」形にした ここが今回いちばん考えたところだ。 選択肢は2つあった。 A:許可が下りるまで待つ(下りなければ、作ったものは無駄になる) B:使えないままでも回る形にする Bを選んだ。 具体的には、Box AIで処理できなかったファイルに対して「Claudeのチャット用の指示文をコピー」というボタンを置いた。押すと、そのファイルに対する指示文とフォルダの情報が丸ごとコピーされる。あとはチャットに貼り付ければ、同じことができる。 自動ではない。ひと手間かかる。それでも、画面を見て「これを分析したい」と思ったその場から、2クリックで先に進める。 「使えるようになったら本気を出す」をやめた この判断は、たぶんこのブログでいちばん伝えたいことに近い。 社内でAIを使っていると、自分では動かせない壁に何度もぶつかる。権限、契約、管理者の判断。どれも自分の努力とは関係のないところで決まる。 そのたびに「解決したら再開しよう」と止めていたら、たぶん何も進まない。実際、以前に書いたできたこと・できなかったことの記事でも、ネットワーク上のフォルダが見えないという制約を、別のツールに運ばせることで回避した。あのときと考え方は同じだ。 制約は消えるのを待つものではなく、そのまま抱えて設計に織り込むもの——これが数か月かけて身についた感覚だと思う。 もちろん、依頼は出してある。通れば儲けもの、くらいの気持ちでいる。 アーティファクト内での制約(実際に踏んだもの) もうひとつ、作ってみて初めて分かったことがある。チャットでできることが、アーティファクトの中では必ずしもできない。 同じClaudeなのに、動く場所によって挙動が違うのだ。実際に踏んだものを書いておく。 制約 内容 ファイルの中身をそのまま取得できない 画像やPDFなどのデータを直接扱うツールは、アーティファクト内から呼び出すとエラーになる 連続で呼ぶと止まる 短時間にたくさん呼び出すと「リクエストが多すぎます」と拒否される。件数の上限を設けて回避した 画面内から呼び出すClaudeは精度が落ちる アーティファクトの中からもClaudeを呼べるのだが、使われるのは軽量なもので、チャットで対話するときほど賢くない。込み入った判断は任せられない(※Box AIとは別の話) 3つ目は特に注意が要る。「チャットでうまくいったから、画面に組み込めば同じことができるだろう」と考えると、たぶん失敗する。アーティファクトは"賢い判断"を任せる場所ではなく、“決まった操作"を並べる場所だと考えたほうが良さそうだ。 ...

2026年9月2日 · 1 分
Copilot CoworkとClaude Coworkの違い

Copilot CoworkとClaude Coworkの違い|Claude Coworkを社内で数か月使った視点で読み解く

先にお断り:まだ使っていません この記事は「Copilot Coworkを使ってみた」という話ではありません。自分はまだ触っていない。 書いているのは、Claude Coworkを会社で数か月使ってきた人間が、Copilot Coworkの公開情報を読んで何を考えたかという記録です。使用感のレビューを探している方には物足りない内容だと思います。 それでも書くことにしたのは、この2つの関係を知ったときに「じゃあ自分がこれまで覚えてきたことは、どうなるんだ」と真っ先に思ったからです。同じ立場の人がいるかもしれない、と考えました。 そもそも「Copilot」と「Copilot Cowork」は別物 まず紛らわしいところから整理します。名前が似ていますが、この2つは違うものです。 名前 何をするもの Microsoft Copilot Office等の中にいるアシスタント。文書作成や要約を手伝ってくれる Copilot Cowork 時間のかかる複雑な作業をまるごと任せられる仕組み。2026年6月に一般提供開始 以前に書いたClaudeとCopilotを使い比べた記事は、上の段の「Microsoft Copilot」との比較でした。この記事で扱うのは下の段のほうです。 公開情報の整理 2026年6月16日、MicrosoftはCopilot Coworkの一般提供を開始しました。公表されている内容をざっくりまとめると、こうなります。 時間のかかる作業を任せられる:複数のツールをまたぐ長時間の処理を、クラウド上で進めてくれる 社内の情報やツールを踏まえて動く:組織の中の文脈を持ったまま作業する 使った分だけ課金される:Copilotクレジットという仕組みでの従量課金 作業内容に応じてAIを自動で選ぶ:複数のAIモデルを使い分ける方針 そして、報道によれば——Claude Coworkの基盤技術とClaudeモデルを、Microsoftのインフラの中で動かしているとのことです。 正直、ここを読んだときは驚きました。 覚えたことは、たぶん無駄にならない 自分がまず気にしたのは、これまで積み上げてきたやり方が使えなくなるのかという点でした。 会社でClaude Coworkを触り始めてから数か月、失敗しながら覚えたことがいくつかあります。しかし中身が同じ系統のAIなら、そのほとんどはそのまま持ち越せるはずです。 具体的にはこのあたり。 ① 従量課金との付き合い方 どちらも使った分だけ課金される仕組みです。だとすれば、46万件のファイルを整理したときの記事に書いた考え方はそのまま効くはずです。 機械的なルールで絞れるところは機械に任せ、AIには判断が要る部分だけを渡す。 課金の名前がクレジットに変わっても、「必要な分だけ読ませる」という原則は変わりません。 ② 頼み方 AIへの頼み方をまとめた記事に書いた6つも、製品が変わって通用しなくなる類のものではないと思っています。ゴールを自分で決める、迷ったときの倒し方を先に渡す、毎回言うことは文書にしておく——このあたりは、そもそもAI特有の話ですらありませんでした。 ③ 役割分担の設計 書類の仕分けを任せたときの記事で書いた「運搬・判断・確認を分ける」という考え方も、道具が変わっても残ります。何をAIにやらせて、何をやらせないかは、製品の仕様ではなく仕事の設計の話だからです。 つまり、乗り換えが起きたとしても、覚え直しになるのは操作方法くらいではないか、というのが今の見立てです。 逆に、気になっていること とはいえ使っていないので、分からないことのほうが多いです。特に気になっているのは3つ。 ① ファイルの置き場所の制約はどうなるのか Claude Coworkで最初に苦労したのが、これでした。何が読めて何が読めないかを調べた記事に書いた通り、ネットワーク上の共有フォルダが見えない、といった制約が最初に立ちはだかりました。 Microsoftの製品なら、SharePointやOneDriveとの相性は良さそうに思えます。ただ、こういう制約は実際に触ってみないと分からないというのが、これまでの経験から学んだことでもあります。 ② 「クラウドで動く」の意味 Copilot Coworkはクラウド上で処理が進むとされています。もしそうなら、書類の仕分けの記事で書いた「パソコンが動いているあいだしか処理が進まない」という制約が、そもそも存在しないことになります。 自分の環境では、退社時にPCを止めるルールがあるせいで、大きな処理を夜間に流せませんでした。ここが変わるなら、できることの幅はかなり広がります。 ③ 従量課金の実感 「クレジット制」と言われても、実際に業務で使うとどれくらいかかるのかは使ってみないと分かりません。Claude Coworkより3〜4割安いと報じている記事もありますが、これは料金表の比較であって、同じ仕事をさせたときの実費とは別の話です。 自分の場合、Claude Coworkでは「1ページ目しか読ませない」といった工夫でコストを抑えてきました。同じ工夫が同じように効くのかどうかは、触ってみたいところです。 「どちらを選ぶか」という話ではない 最後に、これは書いておきたいのですが——多くの会社員にとって、これは選べる話ではないと思っています。 どのAIを導入するかは会社が決めることで、現場の人間は用意されたものを使うことになります。自分もそうでした。 だからこの記事も「どちらが優れているか」を論じるつもりはありません。それより大事なのは、どちらが来ても困らないだけの考え方を持っておくことだと思っています。 そしてありがたいことに、その考え方は製品にあまり依存しませんでした。目の前にある道具で試して、失敗して、覚えたことは、次の道具でも使えます。 少なくとも今回調べた限りでは、そう考えてよさそうです。 ...

2026年8月29日 · 1 分
非エンジニアのためのAIの頼み方

非エンジニアのためのAIの頼み方|技術より効いた6つのこと

効いたのは技術ではなく、頼み方だった このブログではここまで、業務をどう自動化したかを事例として書いてきた。書類の仕分け、記入漏れの通知、46万件のファイル整理——どれも、こちらはプログラミングができないまま作ったものだ。 一通り書き終えて振り返ってみると、うまくいったかどうかを分けていたのは技術の知識ではなかった。何かを覚えたから作れるようになったわけではない。変わったのは頼み方のほうだ。 そして面白いのは、身についたコツのほとんどがAI特有のテクニックではないことだった。人に仕事を頼むときとほぼ同じだったのだ。 この記事では、実際に失敗したり助かったりしながら身につけた6つを書いておきたい。 ① 言葉で説明できないなら、画面を見せる これがいちばん即効性があった。 初めて触るツールは、画面の各部分に何という名前が付いているのかが分からない。だから言葉で説明できない。 「右上の……なんか歯車みたいなやつの下に出てくる、青い文字の部分」 こんな説明で伝わるはずがない。だから画面を撮って貼り付けて、「これのどこを押せばいい?」と聞く。 用語を知らなくても質問できるようになると、調べる時間がまるごと消える。「この機能の正式名称は何だろう」と検索する手間がなくなるからだ。 (この点は使うAIによってかなり差が出た。詳しくはClaudeとCopilotを使い比べた話に書いている) ② 「何が起きているか分からない」まま聞いていい 非エンジニアがいちばん躊躇するのは、たぶんここだと思う。きちんと整理してから聞かないと失礼な気がする、という感覚だ。 でも実際には、こんな聞き方で十分だった。 「フィルターが効かない。空の行があるはずなのに0件になる。なんで?」 症状しか言えていない。原因の見当もついていない。それでも会話は成立するし、むしろこちらが思いつかない仮説を出してもらえる。 このときの答えは「列の名前に、目に見えない文字が混ざっている可能性がある」だった。自力では一生たどり着けなかったと思う。 分からないことを分からないまま渡していい。 ただし、次の点だけは押さえておく必要がある。 ③ 道筋は分からなくていいが、ゴールだけは自分で決める ②と矛盾するようだが、「何がどうなってほしいか」だけは自分で決めておく必要がある。 ❌ 「この作業を効率化したい」 → 何をもって効率化かが分からない ⭕ 「毎朝この表を開いて未入力を探している。これを自動で知らせてほしい」 道筋(どうやるか)は知らなくていい。むしろそこを一緒に考えるのがAIの得意分野だ。でもゴール(どうなったら成功か)を決められるのは自分だけだ。ここを預けてしまうと、それらしいけれど的外れなものが出てくる。 自分の場合、AIに相談するときの型はだいたいこの4つを揃える形に落ち着いた。 伝えること 例 ゴール 未入力の行を毎日チャットに通知したい 場所 対象のファイルはここにある 出力の形 一覧の表で、宛先はこのチャット 判断のルール この取引先は対象外。空欄と「未確認」の両方を拾う この4つが揃っていると、たいてい一発で話が進む。逆に足りないと「これはどうしますか?」の往復が増えて、時間も費用もかかる。 ④ 迷ったときにどちらへ倒すかを、先に決めて渡す これは失敗しかけて学んだことだ。 46万件のファイルを「消していいもの/残すもの」に仕分けてもらったとき、最初に決めたルールがこれだった。 迷ったら全部「要確認」に入れる。 AIに「たぶん消していいと思います」と判断させない、ということだ。確信が持てないものはすべて人間が見る側に回す。 判断を任せるときは、正解の基準よりも「迷ったときの倒し方」を決めておくほうが大事だと感じている。人に仕事を頼むときも同じで、「困ったら止めて相談して」と言っておくかどうかで結果が変わる。 (この話は46万件の整理の記事に詳しく書いた) ⑤ 毎回言うことは、書いて置いておく AIとの会話は、次に新しく始めたときには引き継がれない。前回どれだけ丁寧に説明していても、翌日にはゼロからになる。 だから毎回同じ説明をするはめになる。これが地味に効いてくる。時間もかかるし、従量課金の環境なら費用にも直結する。 解決策は単純で、決まりごとを文書にして置いておくこと。しかもこれは、2段階に分けられる。 全体に効くもの(グローバル指示) 設定画面に書いておくと、どの作業をするときにも効く。ここに書くのは「どの仕事でも変わらないこと」だけにしている。 呼び名や口調 確認のやり取りを最小限にする方針 費用を意識してほしいという方針 その業務だけに効くもの(作業フォルダの指示書) 業務ごとのフォルダに CLAUDE.md という名前の文書を置くと、そのフォルダで作業するときだけルールが効く。自分が書いているのはこういうことだ。 ファイル名やフォルダの付け方のルール 処理が終わったら完了の合図を残すこと この業務で使う言葉の定義 迷ったら業務フォルダ側に書くのがいいと思う。全体に書いたことは全部の作業に付いて回るので、増やしすぎると毎回それを読ませることになるし、他の業務では邪魔になる。 ...

2026年8月17日 · 1 分
Excelでは開けるのに、プログラムでは読めなかった

Excelでは開けるのに、プログラムでは読めなかった|月次の照合作業を自動化した話

月に一度、2つのデータを突き合わせる作業 月次でやっている確認作業がある。 システムに登録された案件のデータと、正しい情報がまとまった台帳。この2つを突き合わせて、登録した時点で正しい請求先が書かれていたかを1件ずつ確認する。書かれていなかったものは後で直さなければならないので、洗い出しておく必要がある。 判断はそう単純ではない。番号で書かれているものもあれば、会社名だけ書かれているものもある。書き方が少し違うだけで実質は合っているケースもある。そもそも確認の対象外にしている取引先もある。 つまり**「これは合っている、これは違う」を人の目で判断していく作業**で、件数がまとまると相当に骨が折れる。これをなんとかしたかった。 最初の壁:Excelでは開けるのに、プログラムでは読めない 作業の入り口は、システムからデータをExcel形式で書き出すこと。これをプログラムで読み込んで処理する——そのはずだった。 ところが、読み込もうとするとエラーになる。**「このファイルは壊れています」**と言われる。 不思議なのは、同じファイルをExcelで開くと普通に開けることだ。中身も正常に見える。壊れているようにはまったく見えない。 「じゃあこっちの書き方が悪いんだろう」と思って何度も試したが、どうやっても読めない。ここでかなり時間を使った。 Excelファイルは、実は「圧縮ファイル」だった 原因を調べる過程で、自分が知らなかったことを知った。 **Excelファイル(.xlsx)は、中身が複数のファイルに分かれていて、それをひとまとめに圧縮した"箱"**なのだ。ZIPと同じ仕組みで、拡張子を.zipに書き換えれば中を覗くこともできる。 そして箱の中には、「どこに何が入っているか」を示す目次が付いている。 今回のファイルは、この目次の部分が壊れていた。 Excelは寛容だった:目次が怪しくても、中身を自力で探しに行って開いてくれる プログラムは正直だった:目次を信じて読もうとするので、「目次が壊れている=このファイルは壊れている」と判断して止まる つまりどちらも正しい動作で、「Excelで開けるから正常なファイル」とは限らないということだった。 目次を作り直して読ませた 対処は、箱の目次を無視して中身を頭から順に探し出し、目次を付け直すという方法をとった。 ファイルの中には、部品の始まりを示す決まった印がある。それを全部拾い出して、正しい構造に組み立て直す。そうすればプログラムからも普通に読めるようになる。 正直、この対処は自分ひとりでは絶対にたどり着けなかった。「Excelでは開けるのにプログラムでは読めない」という症状を伝えたら、Claudeが「ファイルの構造そのものが壊れている可能性がある」という筋を出してくれた。 自分にはそもそも「Excelファイルの中に目次がある」という知識がなかったので、疑うことすらできなかった。 前にも書いたが、非エンジニアがいちばん助かるのは「自分が知らないから疑えないこと」を出してもらえる場面だと思う(ClaudeとCopilotの比較でも同じことを書いた)。 本題:人の曖昧な判断を、ルールに落とす ファイルが読めるようになってからが本題だった。 これまで目でやっていた照合を、機械に任せるにはルールを言葉にしなければならない。やってみて気づいたのは、自分がやっていた判断は「合っている/違う」の2つではなかったということだ。 整理してみると、実際にはこうなっていた。 判定 どういう状態か 一致 正しい番号がきちんと書かれている 不一致 番号は書かれているが、正しいものと違う 名称のみ記載 番号はないが、取引先の名前は書かれている 名称のみ(ニュアンス) 名前の書き方が少し違うが、実質は合っていそう 記載なし 何も書かれていない 対象外 もともと確認の対象にしていない取引先 自分で無意識にやっていた判断を並べてみると、あいだの段階がいくつもあった。これに気づけたのが一番の収穫だったかもしれない。 「ニュアンス一致」という段階を作った いちばん悩んだのが4つ目の**「書き方が少し違うが、実質は合っていそう」**というケースだ。 会社名の書き方は揺れる。「株式会社」が付いているかどうか、略称で書かれているか、前後に余計な文字が付いているか。人が見れば同じだと分かるが、文字として完全に一致はしない。 これを「不一致」に入れてしまうと、要確認の山に大量の"実は問題ない案件"が混ざる。かといって「一致」にしてしまうと、本当に違うものを見逃すかもしれない。 そこで、専用の段階をひとつ作った。「たぶん合っているが、機械が断定はしない」という置き場所だ。 これは前回の記事で書いた「迷ったら要確認に入れる」と同じ考え方だ。白黒つけられないものを無理にどちらかへ寄せず、グレーの箱を用意する。 曖昧なものを扱うときは、これがいちばん事故が少ないと思う。 出てくるのは、色分けされた1つのExcel 処理が終わると、Excelファイルが1つ出てくる。中は9枚のシートに分かれている。 全体の集計(何件中、何件が要確認か) 全件の一覧(判定ごとに色分け) 要確認のものだけを集めたシート そのほか、判定ごとのシート 判定は色で分けてある。合っているものは緑、はっきり違うものは濃い赤、何も書かれていないものは赤、対象外はグレー。 狙いは全件を見なくて済むようにすることだ。以前は全部に目を通していたが、今は「要確認」のシートだけ開けばいい。 これも前に書いた話とつながる。書類の仕分けの記事で「人が見る場所を1か所に絞ることのほうが価値がある」と書いたが、今回も同じだった。自動化の成果は"作業が消えること"だけでなく、“見るべき場所が減ること"にもある。 今は「照合して」と伝えれば、このExcelが出てくるところまで自動になっている。 まとめ この作業から学んだことを3つ。 「Excelで開けるから正常」とは限らない。 システムが書き出したファイルは、見た目が普通でも中身が壊れていることがある 自分の判断を書き出すと、思っていたより段階が多い。 「合っている/違う」の2択でやっているつもりで、実は5〜6段階の判断をしていた グレーの箱を用意する。 白黒つけられないものを無理に寄せず、専用の置き場所を作ったほうが結果的に速い そして毎回思うのだが、詰まったときに効くのは「自分が知らないことを疑ってもらえる」ことだった。Excelファイルの中に目次があるなんて、この作業をするまで知りもしなかった。知らないことは疑えない。そこを埋めてもらえるかどうかが、非エンジニアが自動化を進められるかの分かれ目になっていると思う。

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 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 分