Claude Codeに業務を頼むとき、たいていは「やりたいこと」から話し始めます。ところが先日、順番を逆にして考えてClaude Codeに提案してみたら、AIとの課題解決がスムーズになった経験をしました。
しかもその考え方は、税理士として日々やっていることと同じ構造でした。
AIに「できないこと」を先に聞き、課題解決を提案した
事務所では複数のAIを使い分けています。
パソコンの中メインで動くAI（Claude Code）と、クラウド側で動くAI（Claude、Claude Cowork）。
それぞれによいところがあるので、掛け合わせて運用していくナレッジフォルダを作りました。
その際、Claude CodeとClaude Coworkが同じ資料を扱うため、お互いへの申し送りを残す「連絡帳」を用意しました。1つのファイルに、それぞれが下から書き足していく方式です。
ところが運用を始めてすぐ、この設計が成立しないと分かりました。
Claude Coworkには、既存のファイルに書き足す機能がなかったからです。
Claude Cowork側でできたのは、次の操作でした。
- 新しいファイルを作る
- ファイルをコピーする
- 中身を読む
- ファイルを探す
- 更新日時などの情報を見る
読むことも、探すことも、新しく作ることもできる。
ところが、あるファイルを開いて末尾に書き足す操作だけが、どこにもありませんでした。
上書きもできません。
手が届くのは「新しく置くこと」までで、「すでにあるものを書き換えること」ができない状態です。
Claude Codeのほうは、同じファイルに追記できます。
どちらも同じGoogle Driveを見ているのですが、MCP・コネクタが、それぞれ別物だったからです。
Claude CodeがつないでいるMCPには追記の機能があり、Claude Cowork側のコネクタにはそれが無かったのです。
私は、この違いを確かめないまま連絡帳を設計していました。
連絡帳という設計が、根本から崩れてしまいました。
Claude Codeの回答は「回避策が三つあります」
Claude Codeに相談すると、すぐに3つの案が返ってきました。
①別のファイルを新しく作ってそこに書く。
②内容を画面に出すので私が手で貼り付ける。
③次回の作業に持ち越す。
どれも「連絡帳を届ける」という目的から逆算した答えです。
理屈は通っていますが、そのつど経路が変わるので、書くほうも読むほうも迷う仕組みになってしまいます。
動かない壁を、三方向から押しているような状態です。
そもそも手動で貼付けるというのが今後の運用を考えるととても面倒そうでした。
順番を逆にしたら、制約ごと消えた
このとき私が考えたのは、別のことでした。
Claude Coworkは、そもそも何ができるのか。
新しいファイルを作ることはできる。
ならば、連絡帳を一つのファイルにする必要はないのではないか。
フォルダを1つ作り、連絡事項ひとつにつきファイルを一つ作って入れていけばいい。
そう決めた瞬間に、追記できないという制約は問題でなくなりました。
さらに、複数のAIが同時に書いても衝突しない。
上書きで内容が消える事故が、構造的に起こらない。
ファイル名を日付から始めれば、並び順がそのまま時系列になる。
自然とこの発想が出てきたのですが、これは意外と毎日やっていた思考法なのでした。
税務の仕事は、もともと制約から考える（制約思考）
目的から考えるやり方は、やりたいことを先に決めて、そこから制約をどう回避するかを探します。
制約から考えるやり方は、使える道具の可否を先に確かめて、その枠の中でどう形を作るかを探します。
制約が動かせないものだったときには、後者のほうが圧倒的に速く答えにたどり着きます。
「なんとか経費にできないか」から入らない
税務実務は、本質的に「制約思考」です。
まず制度の上でできること・できないことを押さえ、そのうえで、その枠の中で最も有利な形を組み立てます。
「この支出をなんとか経費にできないか」という順番で入ることはありません。
ここを目的から攻めると、無理や歪みが生じ、あとで否認されるリスクが高いものが出来上がってしまいがちなのです。
つまり、思考の順番を守ることが、そのまま安全につながっているわけです。
枠を嘆くよりも、枠の中で形を作るほうが早いという場面がよくあるのです。
キャッシュフローコーチの現場でも同じ
お金の話をするときも、順番は同じです。
最初から「打てる手を全部出してみましょう」から始めることが、あまりありません。
先にお伺いするのは、「まずは動かせないものは何か」という問い。
毎月出ていく固定費、借入の返済、季節による売上の波。
そして、このあたりを先に置くと、逆に、動かせる部分がくっきり浮かび上がります。
動かないものを先に確定させて、残りの余白に目を向ける。
つまり私は、職業として毎日やっている手順を、AIの設計にそのまま持ち込んでいただけなのでした。
専門職として身につけた思考の癖が、まったく別の分野で効いた。
そう考えると、士業の訓練というのは案外、これからの道具を扱う技術そのものかもしれません。
その制約は、硬いのか、柔らかいのか
この考え方には弱点もあります。制約から考えると、その制約自体を疑わなくなるのです。
今回うまくいったのは、幸運な面もある
先ほどの連絡帳の話には、疑われないまま残った前提があります。
そのファイルをGoogle Driveに置く、という前提です。
同じGoogle Driveでも、つなぎ方が違えば追記はできたのでした。
私が疑わなかったのは、Google Driveそのものというより「この組み合わせでやる」という前提のほうだったのかもしれません。
つまり私は「追記できない」という制約は正しく受け入れましたが、その組み合わせを選んだ前提のほうは最後までは検討していません。
結果として良い設計になりましたが、たまたまその制約が、本当に動かせない本物の制約だったという面はあります。
顧問先との会話でも、同じことが起きる
これは仕事の現場でも起こります。
たとえば事業承継の相談で、「税務上こうなっています」から話し始めたとします。
時価より低い価額で株式を譲れば、その差額は贈与とみなされる。
これは動かせないルール（制約）です。
ただ、そこから入ってしまうと、話は「では、いくらで渡すか」の1点に絞られ、かつ、その道筋を疑わないままに進んでいってしまいがちです。
「そもそも今この株式を動かす必要があったのか」という問いに戻りにくくなります。
制度の話は正確でも、経営者が「本当に困っていたこと」を取りこぼしてしまいます。
制約から入る人ほど、この落とし穴にはまりやすいと感じています。
大事なのは、どちらで考えるかではない
目的から考えるのと制約から考えるのと、どちらが優れているという話ではないということ。
本当の技術は、その制約が硬いのか柔らかいのかを見分けることのほうにあります。
- 硬い制約は受け入れて、こちらの形を変える。
- 柔らかい制約は、そもそも本当かと疑ってみる。
見分け方には、ある程度の目安があるとは思います。
道具の仕様や法令の定めというものは、たいていは硬い制約です。
一方で、「これはこういうものだ」という言い方で語られているものは、柔らかいことが多い。
今回の例でいえば、Claude Coworkに追記機能がないというのは「硬い制約」でした。
「連絡帳とは一つのファイルである」は、私が勝手にそう思っていただけの柔らかい制約。
この見極めさえ合っていれば、あとは自然に形が決まります。
