AI で「自分専用の道具」を作って、業務環境を自己最適化する

はじめに

仕事をしていると、細かいストレスが積み上がっていきます。 例えば、コピペした文字列に余計な装飾がついてくるがこれを取り除きたい、パスワードを作りたい時にジェネレータを毎回検索したり立ち上げる、チャットで連絡された内容がどこにあったかが思い出せない、作業報告のたびに、作業内容を決まった形式に手で書き直すなどです。

単独で見れば、どれも数秒から数分で終わる作業です。 そのため、これまでは問題を解消しようとしてもそのコストの方が大きくなるようなものばかりで、毎日少しずつ時間と集中力を削られていました。

もちろん、この手の作業を助けてくれるツールを探せば大抵見つかります。ただし、実際に使うまでには2つの壁があります。

1つは導入の壁です。業務端末では、ルール上インストールできるソフトウェアが限られる場合があります。 もう1つは導線の壁です。仮に導入できたとしても、自分のユースケースに完全にフィットしたものはなかなか見つかりませんし、別アプリとして立ち上がっているものへ都度切り替えるコスト自体が、地味なストレスとして残ります。

では、その都度 AI に頼めばいいかというと、それも噛み合いません。数秒で終わるタスクのために毎回チャット欄を開いて応答を待つのは非効率ですし「記録しておいて」という用途では、保存した内容がそのまま返ってくる保証がありません。

そのため AI を毎回の操作主体にするのではなく、道具の一部として埋め込むのが適切だと考えました。具体的には、次のように切り分けています。

• 数秒で終わる決まりきった処理 → AI を挟まず、ただのコードに処理させる
• 非定型な入力を定型フォーマットに変換する処理 → AI に任せる
• 記録・保存 → SQLite に持たせる。保存したものが必ずそのまま返ってくる状態にする 

これらの業務に AI を直接使うのではなく、AI に道具を作らせて、その道具を業務に使うという方針を取りました。この記事はその実践例です。

実際に作ったもの

私は WSL2 上に Flask 製の小さなウェブアプリを置いて、自分専用のポータルサイトとして使っています。

記事の執筆時点で、このウェブアプリは以下のような機能を持っています。

1. Chatwork のログから作業報告を作る

日々のやり取りは Chatwork に残っています。ここから「何をやったか」を抽出して、報告用のフォーマットに整形する処理を Gemini に任せています。 実際には Chatwork の URL を渡すことで、その投稿内容を Chatwork API によって確認し、もし返信だった場合は３段ぐらい遡ってデータを取得しています。

自分でやると時間が掛かるのは、特定フォーマット（ここではスプレッドシート）に決まった形で入力する部分です。 そのため、こちらで Chatwork から URL だけを取得して、実施日付、概要、作業URLなどを抽出して、スプレッドシートに直接貼り付けした後、間違えた部分だけを手動で修正するということが簡単にできるようにしました。 

なお、業務上のやり取りを外部 LLM に投げる部分については、Chatwork に記載された内容のみを利用すること、Gemini の有償版を利用して学習に使われないようにすることなどを考慮しています。ただし、この判断は所属先の規定によって変わりますので、同様のことを試す場合は、各自の環境をご確認ください。  

2. 業務中に普通に使う文字列処理

実際には数秒で終わるのですが、地味に出番が多いのが以下のような文字列処理です。

• コピペした文字列から装飾を剥がす
• パスワードを生成する
• UUID を生成する

これらをポータル上から作成しています。 DevToys などのソフトウェアを使ってもよいのですが、別アプリケーションとして立ち上がっているものを利用するより、やり取りのメインで利用しているブラウザでこれらの処理を行えた方が個人的には非常に都合がよいため、自分専用のポータルアプリの機能として実装しました。 

3. 作業メモとタスク一覧の保存

チャット内容やメモなど、後から参照したいものを、更新があったら自動的に控えておく仕組みです。ブラウザ上で更新があったら自動的に内部の SQLite に保存しているので、簡単には消えません。

これは最初は存在しませんでした。作っているうちに、Chatwork で記載が無い状態（例えば定例ミーティングを実施した、あるミーティングが早く終わって別件のミーティングを行った、など）が業務上で結構あることに気づき、これらを忘れないようにするためにあれば便利と思って実装した機能です。 非常に単純な機能ですが、実際に使ってみると効果は大きかったと感じています。

また、メモを書いていると今度は作業待ちタスク一覧を作りたくなりました。 ここはメモでも良かったのですが、個別に順序を編集できたり、終わった部分をすぐに削除するなどを考えると、リストとして管理することを考えました。

この機能の作り方として、まずは項目を考えて、それらを入力した内容から Gemini に自動的に埋めさせるようにしました。 そして、もし想定外の値を入力された場合は編集で自分で修正する、というように入力の手間を減らす工夫を行いました。

作っていく中で分かったこと

物足りない・不便と感じたら、その場で改善

例えば、先ほどのメモ機能は、こんな順番で育ちました。

1. まずメモを 1 つだけ持てるようにした
2. 使っていたら複数欲しくなったので、タブで切り替えられるようにした
3. タブが増えたら区別がつかなくなったので、名前を付けられるようにした
4. 特別な用途（タスク一覧）が欲しくなったので、新たにタスク一覧機能を実装した

見てのとおり、事前に要件を考えていません。使いながら不便に思ったところを順に足しただけです。

こういう作り方ができるのは、変更が安いからです。従来なら「複数対応」はそれなりの改修になるので、最初に設計しておこうという力が働きました。今は実装が数分で終わるので、考えるより試すほうが早くなります。利用者が自分しかいないぶん、いかに自分にとって都合がいいかだけを考えれば済みます。 

CLI ではなく、ローカルのウェブアプリにした

CLI ツールは作るのは楽で、UNIX哲学にあるように組み合わせることで力を発揮します。 しかし、今回解決した業務は、主にブラウザが主体となって行っている業務です。 そのため、使うときに逐一ターミナルを探して、コマンドを実行したり、別のDevToysなどのソフトウェアに切り替えるというのが地味なストレスでした。 それらを分析すると、自分のためのツールは常時稼働しており、ブラウザのブックマークでタブを開いておいて使うのが、自分にとっては一番ツールを利用しやすい状態になると考え、アプリケーションを実装しました。 

私は WSL2 上で開発しているので、systemctl に user unit として登録して、localhost:17000 で常時動かしています。ポート番号は普段の開発と被らないところを選びました。WSL2 を選んだのは、仕事の時は基本的に常時 WSL2 が稼働しているので、そこに一個足すのが一番簡単だったからです。

起動時に立ち上げっぱなしにする仕組みは、どの OS にもあります。macOS なら launchd、Linux なら systemd の user unit、Windows ならタスクスケジューラでログオン時に起動する、といったところです。

フォーマットへの流し込みは AI に任せる

先に記載した通り、Chatwork の分析やタスク一覧の保存では、まず内部の構成（データ構造）だけを自分で決めて、そこへの分解と流し込みを Gemini にやらせています。

決まった項目に逐一入力するのではなく、雑に投げて分解させ、おかしければ後から直す、という方針です。入力の手間が消えるぶん、多少の修正が発生しても差し引きで大きくプラスになります。

実装の割り切りとセキュリティ

本件の開発は Claude Code で行いました。要件を事前に固めず、使っていて不便に感じた点をその場で伝えて直させる、という進め方です。

また、ウェブアプリを作る場合は通常、複数人での同時更新によるコンフリクト、認証、API キーの管理などを考える必要があります。今回はこれらを割り切っています。

• ローカル限定：自分のローカル PC 上でのみ動かす前提で、127.0.0.1 にバインドしており、同一ネットワークの別端末からのアクセスは受け付けないようになっています。
• 利用者が自分ひとり：同時更新のコンフリクトを考える必要がなく、認証も設けていません
• API キー：Chatwork の API トークンと Gemini の API キーは .env にまとめ、リポジトリには含めていません

逆に言えば、この割り切りが成立するのはローカル専用だからです。同じものを社内の共有サーバーに置いた瞬間、これらの考慮も必要になります。個人ツールの実装が単純で済むのは、使う人間が自分しかいないという前提を最大限に利用しているからです。

おわりに

今回作ったものは、生産性ツールというよりは、自分を最大化するための投資だと思っています。記事の中で「個人的には」という文言を多用した通り、ここに記載した内容は「著者にとって使いやすい」という基準であり、他の人には使いづらいこともあります。 しかし、自分の手癖に完全に合っているという一点で、既製品より快適に使えています。

これを開発成果物と捉えた時「車輪の再発明では」と言われそうですが、これは自己最適化だと考えています。 世の中に似たツールがあることと、自分にぴったり合うツールがあることは別の話です。汎用品として作られたものと、ただ自分のためだけに作られた一点ものでは、機能が同じようなものであっても中身が異なります。 実装が単純になり、AI でも数度のやり取りで作れます。 単純だから壊れにくく、壊れても自分の都合だけで直せる。この連鎖が個人ツールの強みです。

そして最後に。

現時点では、世の中に出ている AI 活用の話は「AI に都度依頼して業務を進める」ものが大半であると感じています。しかし、今回紹介したように AI に道具を作らせて、その道具を業務に使うという方向も、選択肢として持っておく価値があると感じています。 

AI によってツールを作るコストが下がりきった今、既製のソフトを探してインストールして慣れるより、自分で作ってしまったほうが満足できる場面は確実に増えています。

あなたが毎日やっている手作業のうち、いちばん小さくてつまらないものは何でしょうか。それを解決するための仕組みを AI に作らせてみるのはいかがでしょうか？

※ロゴ引用元