AIはパズル。日常の違和感から始めるAIとの付き合い方

本記事では、エンジニアがつくってきた“自分仕様のAIツール”をご紹介します。エージェントやBot、LLM連携ツールなど、実用的なものから、ちょっと遊び心のあるものまで。プロンプト設計やUIの工夫、うまくいかなかったことや思いがけない発見を通して、AIとの付き合い方をのぞいていきます。AIをどう使うかだけでなく、どんな距離感で付き合っているのか。誰かのAIとの向き合い方が、あなたとAIのちょうどいい“さじ加減”の手がかりに。

こんにちは、yamadashyと申します。仕事ではソフトウェアエンジニアをしながら、趣味で日常を少し便利にするツールをつくっています。 最近はその延長で、リポジトリをLLMに渡しやすい形にまとめるCLIツール「Repomix」を開発しています。

私は、日常の「ちょっとした不便」を見つけると、解くべき問題を一つに絞り、できるだけ小さく、できるだけ単純に解決したくなります。

この記事では、Repomixを例に、AIとどう付き合い、どこまで任せ、どこを自分で握るのかを整理します。

ものづくりはいつも「これが欲しい」から始まる

これまで私は、仕事でも趣味でも、身の回りの摩擦を少しずつ削るようなものをつくってきました。 Slackのチャンネルが増えすぎて見づらいと感じればグループ化する拡張をつくり、Googleスプレッドシートのタブの位置が気になれば上に移す拡張をつくり、企業のテックブログを追いかけるのが面倒ならRSSをまとめる仕組みを用意する。

この感覚の原点は、もっと昔の経験にあります。 世の中にはすでに似た道具がたくさんあったのに、なぜか自分の手元だけはしっくり来ない、という瞬間がありました。 そこで既存の選択肢を追いかけるのをやめて、ある「一つの手順」だけに用途を絞った小さな道具をつくったんです。 画面にあるのはボタンが二つだけ。あとは迷わせない、という割り切りでした。 すると不思議なことに、同じ引っかかりを抱えた人にちゃんと届きました。 自分の中では、その感覚をひと言でまとめるなら「すぐ使えて、あとから効いてくる」です。

ここで、同じように見えて結果が分かれる経験がありました。 「こういうのがあったら面白い」と思ってつくったものは、だいたい見向きもされません。つくっている最中は楽しいのですが、問題設定が曖昧なまま完成してしまい、使われ方が定まりにくい。 一方で、私自身が「これが欲しい」と言い切れるものは、想定より多くの人に使ってもらえることがありました。

有名な言い回しに「自分の問題に取り組むことで、その問題が実在することが保証される」という趣旨の言葉があります。 私はこれを、もっと素朴に解釈しています。 自分が困っているなら、そのツールの最初のユーザーはすでに一人いる。つまり、自分です。

Repomixも、まさにこの延長線上にあります。

Repomixは「渡し方」を整える道具

Repomix（repomix.com）は、リポジトリの内容を一つのファイルにまとめ、LLMに渡しやすい形へ変換するCLIツールです。 コードを理解させること自体が目的ではなく、「理解に必要な情報を、過不足なく、再現可能な形で渡す」ことに焦点を当てています。

この手の作業は、やろうと思えば手作業でもできます。 毎回、渡す範囲を選び、ファイルを集め、貼り付け、やり取りの中で差分が出ればまたやり直す。こうした小さな摩擦が、思考の流れを途切れさせます。

私はこの摩擦をツールで消してしまいたかった。 Repomixはそのための道具です。

きっかけは「コスト」と「手戻り」

2024年の夏ごろ、私はClaude Proを契約し、同じ時期にCline（当時の名称は別でした）も使い始めました。 エージェントは便利でしたが、試行錯誤の回数がそのまま費用に直結する感覚があり、気持ちよく回し続けるには負担が大きいと感じていました。

当時は、Clineへの指示を数回試すだけで「昼飯代が消えたな」という感覚がありました。 もちろん、コストをかけてでも学ぶ価値があることは分かっていました。 ただ、試行錯誤の単位がそのまま課金の単位になると、検証のテンポが一段落ちます。 だからこそ、試行錯誤を増やすほどコストも手戻りも増える状況が、心理的に回しづらかったんです。

もう一つ厄介だったのが、手戻りです。 当時の体験では、意図と違う方向へ進んだときに修正を重ねるより、一度巻き戻してやり直したほうが早い場面がありました。 この「巻き戻し」を繰り返すほど、入力（与える情報）の品質と手間が効いてきます。

当時はSlackのチャンネルをまとめる拡張（Slack Channels Grouping）の改修を試していて、Claudeに渡すために、ファイルを手で選んでアップロードしていました。 数ファイルなら成立します。しかし、対象が増えたり、相談の粒度が変わるたびに、同じ準備作業が挟まります。

そこで私は、まずは手元でファイルを結合して試し、うまくいくことを確認しました。 そして「この手順自体を、再現可能な形で固定したい」と考え、Repomixとしてまとめました。

ちなみに、Repomixの初期実装もまた、ファイルを一つずつ渡しながらつくりました。自分の問題を解決する道具を、当の本人がその問題と付き合いながらつくっていた。これが、Repomixの性格を決めた気がしています。

こだわりは「問題を増やさない」こと

Repomixの設計で意識しているのは、「便利そうに見える別問題」をむやみに引き受けないことです。 LLMに渡すための前処理、という一点に集中し、入力から出力までを短い経路に保つ。 「できること」を増やすより、「迷わずできること」を増やしたかった。 コマンド一発で結果が得られ、何度でも同じ手順でやり直せる。これが最も重要な要件でした。

とはいえ、入口の間口はできるだけ広く取りたいので、周辺のニーズに応える機能も少しずつ入れています。 ただしそれらは、必要な人だけが踏み込める「奥行き」として用意し、デフォルトでは迷わず使える体験を守っています。

この方針は、開発の進め方にもつながっています。 私は、何を解くべきか（要件と制約）を決めるところまでは自分が握り、そこから先の実装はAIに寄せます。 理由は単純で、要件と制約が曖昧なまま実装を進めると、速度は上がっても方向がブレるからです。

主戦場は移ったが、出番は残る

サブスク型のAIエージェントが普及し、開発の主戦場は大きく変わりました。 私自身、日々の実装はCursorやClaude Codeへ寄りましたし、いまのRepomixは「実装のための道具」というより、「相談や調査のための土台」として使うことが増えました。

少なくとも私自身にとっては、役目は少しずつ薄くなっています。いまのRepomixは、前に出る道具というより、必要なときに効いてくる「裏方」に近いです。

一方で、世の中全体の利用が減っているかというと、断言はしにくいとも感じています。 Redditなどの議論を眺める限り、以前ほど熱量高く語られなくなった印象はあります。 ただ、私の観測範囲では、熱心に使い続けている人もいて、「下がっている」と言い切るほど単純ではありません。 まだ限定的ではありますが、ローカルLLMの文脈でも名前を見かける機会が少しずつ増えています（観測範囲内の話です）。

私はここを「旬が過ぎた」とまとめるより、「用途が絞られた」と捉えています。 エージェントがカバーする領域が増えた結果、Repomixが強いのは「相談や調査のための土台を、最短で用意したい」ときのような、より限られた場面になりました。 それでも、リポジトリを一つの成果物に圧縮し、任意の場所へ持ち運べる、という性質は残ります。

いま私がよくやっているのは、ClaudeのWeb版（ブラウザ／アプリ）にあるClaude Projects（文脈の置き場所）にRepomixの出力を置いておき、IssueやDiscordの相談をそこで素早く行うことです。 私の中では、用途を「能力」ではなく「文脈の置き場所」で分けています。Claude CodeやCursorなどのエージェントは実装を主戦場にしつつ、相談も含めて大抵のことができます。 一方で、Repomixでパックした成果物をClaude Projectsにまとめておくと、調査や相談の起点として使いやすいです。 実装の作業は主にエージェント側で進めます。その代わり、文脈がデバイスではなくProjectに紐づきます。 だから、スマホでもPCでも同じ前提からすぐ再開でき、複数の場面で考えを引き継ぐ用途に強いです。

もちろん、線引きを厳密に守っているわけではありません。実装中にエージェントへ相談することもあります。それでも「相談・調査の基準点となる入力」をProject側に寄せておくと、状況説明や文脈の再同期が減り、思考の流れを保ちやすくなります。

ちなみに、RepomixはOSSとして公開しています。私の考えとしての補足ですが、OSSにする価値の一つは「自分が持っていない問題を持つ人とつながれる」ことだと思っています。 最近も、Issueで「RepomixでClaudeのAgent Skillsを生成できないか」という提案をもらい、実際に取り込みました。自分の発想だけでは出てこなかった切り口で、確かにそれは便利だなと思いました。 こうした外からの要請で道具が少しずつ更新されるのも、Repomixにまだ「出番のある場所」が残っている、という一つの手がかりだと感じています。

AIは「物理演算パズル」を遊ぶように

ここからは少し視点を引いて、私がAIとどう付き合っているか、その「間合い」の取り方について触れておきます。

AIの出力には不確実性があります。 ただ、私はそれを「運」だけの話として捉えていません。 むしろ、物理演算のパズルに近い。 角度や力の入れ方を少し変えるだけで結果が大きく変わる一方で、手応えが掴めてくると、狙って結果を出せる範囲が広がっていきます。 ときどき思わぬ跳ね方をして外れることもありますが、「だから運任せ」というより、盤面を見直して再現性を上げていく感覚です。

この比喩でいうと、盤面（制約と文脈）があり、ピース（入力と指示）があり、立ち回り（試行の順序）があります。

私が握りたいのは盤面です。 何を解くのか、何を解かないのか、どこで折り返すのか。 ここが定まっていれば、ピースの置き方はAIに任せても、全体は崩れにくい。 逆に、盤面が曖昧なままピースを増やすと、動いているように見えて、結局どこにも到達しません。

この流れで捉えると、Repomixは「盤面を整える」ための道具、とも言えるかもしれません。 リポジトリの情報を一つの成果物にまとめておくと、AIに渡す文脈を揃えやすくなります。たとえば、Repomixでパックしたリポジトリを添付しながら、突然カレーのつくり方を聞くような、文脈と問いがズレた投げ方はあまりしないでしょう。 添付した文脈と問いが噛み合っているほど、少ない指示でも話が進みやすくなります。 盤面が揃っていれば、あとは「何をしたいか」を短く添えるだけで、狙った方向に寄せやすい。

そして結局、盤面を整えるほど「何が問題で、次に何へ取り組むべきか」が見えやすくなります。

差が出るのは「問題の発見」と「課題化」

AIが普及して感じるのは、実装の敷居が下がった以上に、「問題を問題として扱えるか」が差になっていることです。 ここでいう「問題」は、いま困っている状態（あるいは避けたいリスク）と、あるべき状態のギャップです。 そして「課題」は、その問題を解決するために、次に取り組むべきこととして切り出した作業単位です。 問題を見つけ、言葉にし、課題へ分解し、制約を置き、検証可能な形にする。 この一連ができれば、解決の手段はAIでもSaaSでもよく、必要ならエンジニアが仕上げればいい。

最近、身近なところでもその変化を実感しました。 妻が月額で使っていた簡易なサービスがあり、要望を聞いてみると、欲しいのは機能の多さではなく、動きの癖と手触りでした。 AIエージェントを使って短時間で同等のものを作れたのは、実装が速くなったからというより、要件が明確だったからだと思います。

もう一つ、AIが効く場面があります。 新しく作るより、既にあるものを保守する場面です。 互換性のある更新は自動化で回せても、互換性のない更新や周辺影響の読みは、人の判断が残ります。 その判断を助ける材料（コード、履歴、意図）を揃えるところで、AIはよく働きます。

最後に、私が大事にしている原則を書いて終わります。

問題を見つけ、それを課題に分解し、要件に落とせた瞬間、解決はもう半分終わっています。 残り半分は、AIやSaaSや、あるいはあなたの手が解いてくれます。

そして問題は、意外と「対話」よりも「沈黙」の側で育ちやすいと感じています。 もちろん例外はありますが、私の場合はそうでした。 人に話す前に、まず自分で不便に向き合い、言葉にしてみる。その時間が、その問題の一番の理解者をつくります。

最初のユーザーは、いつもあなたです。 それだけで、始める理由としては十分だと思います。