はてなブックマーク

TLDL バイブコーディングで制御しきれなくなった GUI アプリがあったら AI に、以下の指示をそのまま伝えてみてください。 すべてのコンポーネントを Root からなる階層構造下に置き、各コンポーネントは MVP パターンの Passive View として描画に関わるパラメータだけを操作し、動作は Chain of Responsibility でイベントをバブリングさせて、ステートマシンとして振る舞う Mediator に裁定させること。 はじめに 「CooSenpAI」というmacOS 上で常駐するAIアシスタントを最近開発してます。 これは AI に指示を出さなくても、ユーザーのやってることを理解したり、かゆいところに手が届くショートカットを多数もっている便利なツールです。 便利な反面仕組みは地味に複雑です。 キーボードの特定のキーを押すと画面の範囲選択や文章のコピーができま

AI への指示書は自然言語で書きます。 書いた本人には明確に見えますし、AI も分かったという顔をして実装を始めます。 その結果、できあがったものが思っていたものではないことがあります。 なぜなら、自然言語は解釈が揺れるからです。 私が開発している OSS の TAKT では、この揺れを実行前の対話で潰しています。 具体的には、アシスタントとタスクを詰めて合意した内容を、指示書にまとめてからエージェント群に渡すようにしています。 この指示書の受け入れ条件はこれまで Gherkin で書かせてきました。 v0.61.0 でここに形式仕様モードという設定を足しました。 有効にすると、指示書の要件を Quint と Alloy という記法でも表現するようになります。 形式手法は正しさが欲しい場面で昔から使われてきた道具です。 ただ実務で常用するには仕様を書いて維持するコストが高く、採用できないと

OpenAI や Anthropic のフロンティアモデルの性能はとてもよいのですが、経済性がよくありません。 日次や週次のレート制限がどれだけあなたを苛立たせたでしょう。 また、毎日の仕事道具の生殺与奪を誰かの方針に握られているのも気に入りません。 この不快感を強く感じたシーンは何度もありました。 OpenAI が誤って私を BAN した日（みんな大騒ぎしてましたね）。 Anthropic が SDK 利用をサブスクリプションから排除すると発表した日（現在ではうやむやになりました）。 RateLimit で何もできなくなった日。 とおもったら Rate Reset の嵐で使い切らないといけない焦燥感に睡眠時間が削られるようになった日々。 なにか大きな発表や変更があるたびに私の心は不安な方向に揺さぶられていました。 しかしながら、この便利すぎるツールを放棄する手はありません。 私が使わなく

TAKT を Product Hunt に出します！ 8/9 に公開されます。 Product Hunt はローンチ当日の反応でランキングが決まり、上位に入るほど海外の開発者に届きます。 当日、見に来て応援してもらえると嬉しいです。 https://www.producthunt.com/products/takt-3?launch=takt-3 最近 AI が暴走して他社に攻撃してしまった。 そんな話が耳に入りつつ、自分とは関係ないことだと思っていました。 そう、過去形です。 実は私はここのところ、ずっとモデルの性能アップと格闘していました。 モデルの精度が上がり、指示への遵守性が上がったことで、TAKT が無限に近いループを起こすようになってしまったのです。 TAKT には、内部エージェントが利用するビルトインのプロンプトが大量に入っています。 この1週間だけでプロンプト関連の fix

はじめに 「ループエンジニアリング」という言葉が話題になっています。 ざっくり言うと「自分がエージェントに指示を出す役割を、システムに置き換える」という考え方です。 人間がプロンプトを書いてはエージェントの出力を確認して、またプロンプトを書いて、という往復をやめる。 代わりに作業→レビュー→修正のループをシステムとして設計して自動的に回す。 プロンプトエンジニアリングが「1ターンごとに何を伝えるか」の技術だったのに対して、ループエンジニアリングは「ループ全体をどう設計するか」の技術です。 エンジニアの役割が「プロンプトを書く人」から「ループを設計する人」に変わるということです。 TAKT はまさにこれを実践するツールです。 やっと世の中が TAKT に追いついてきましたね。 TAKT は複数のAIエージェントにそれぞれ役割を与えて、作業→レビュー→修正のループを自動的に回すオーケストレーシ

はじめに プロンプトが長く、そして増えてくると、どんどんと保守性が下がってきます。 役割、ルール、知識、作業指示、出力形式。 最初はひとつのファイルに入っていても困りません。 ところが運用を続けると、一部だけ差し替えたい、同じルールを別のスキルでも使いたい、Claude Code と Codex の両方で使いたい、といった欲が出てきます。 そのたびに長いプロンプトを丸ごと編集するのは、かなりつらい。 これは大きな課題です。 以前、私はこの問題に対する考え方として、Faceted Prompting というものを書きました。 今回はその考え方を実際に使うための npm モジュール faceted-prompting についてお話します。 このモジュールは、プロンプトを部品として管理し、system prompt と user prompt にもしたり、Claude Code や Codex

はじめに Claude Code PR Review がリリースされましたね。 ドキュメントを読んでみると、カスタマイズの手段として CLAUDE.md と REVIEW.md が用意されています。 レビュー時に考慮してほしい観点をこれらのファイルに記述できる仕組みです。 プロジェクト固有のルールやコーディング規約を伝えておけば、レビュー時にそれを考慮してくれます。 エージェントのカスタマイズは限定的で、内部エージェント構成の変更は今のところできないようです。 したがって、REVIEW.md で観点の追加などは可能ですが、「その観点を必ず実行する保証」がない。決定論的な担保がありません。 そのことがどのように影響するのか。この記事では、このあたりを掘り下げていきます。 レビュー観点は誰が決めるのか AI エージェントにレビューをさせるとどうなるか。まずはこの話から始めましょう。 AI の知

はじめに 皆さんはもう AI コーディングツールを使っているでしょうか。Claude Code や GitHub Copilot、Cursor など、さまざまなツールが登場して、「AI がコードを書いてくれる時代」がやってきました。 私も例に漏れず、その恩恵に預かろうと意気揚々と AI コーディングを始めました。これまでの生活はプログラミングと家事の二本柱。 AI がコードを書いてくれるなら、プログラミングの時間が圧縮されて、自分の時間が増えるはず。溜まった洗い物や洗濯物を片付ける余裕が生まれるはず。そんな期待を胸に。 ところが現実は違いました。 AI がコードを書いている間、私は画面の前に張り付いていたのです。AI の出力をチェックし、軌道修正し、承認し、またチェックする。気づけば一日中 AI の相手をしていて、洗い物は溜まる一方。プログラミングに費やしていた時間が「AI のお世話」に置

はじめに 現在、TAKTというAIエージェントオーケストレーションツールを開発して常用います。複数のAIエージェントを束ねて、実装→レビュー→修正のサイクル等を柔軟に定義して、自動的に回すツールです。 TAKTはClaude CodeやOpenAI Codex、Anthropic APIやOpenAI APIなどのプロバイダーに対応しています。しかし、いずれも利用には課金が必要でした。「TAKTを試してみたい」と思ってくれた方にも、まず有料のAIサービスを契約してもらう必要があったのです。 それが、opencode対応によって変わりました。 いまや、誰でも無料でAIエージェントのオーケストレーションを体験できます。 きっかけは「AIが足りない」 opencode対応のきっかけはRate Limitに到達したことです。いかんせん富豪的AIコーディングをしているせいか、Claude Code

はじめに プロンプトが巨大化している。どれを修正すべきなのだろうか。 エージェントの役割、行動規範、タスク固有の指示、ドメイン知識、出力形式。これらがすべて1つのプロンプトファイルに混在している。最初は小さかったはずのプロンプトが、気づけば数百行に膨れ上がっている。 これが直近の私の課題であり、人類の課題になるだろう――。 ということで、この問題に対する解決策として「Faceted Prompting」というアーキテクチャを考案しました。本稿ではこのアーキテクチャの考え方と実践方法を紹介します。 モノリシックなプロンプトが生む3つの問題 プロンプトがモノリシックになると、何が困るのでしょうか。私が直面した問題は3つありました。 まず、再利用できません。2つのステップが同じレビュアーのペルソナを必要としつつ、指示が異なる場合を考えてみてください。プロンプト全体を複製するしかありません。ペルソ

たったこれだけで、TAKTのワークフローがClaude Code Skillとしてエクスポートされます。今まで積み上げてきた資産が、そのまま新しい環境でも活きるのです。 コマンド体系としてはtaktのyamlを指定する形になるので、次のような形です。 どんなyamlがあるかはtaktのREADMEかここあたりに↓。 実際試した感じがこちらです。 ほかにも TAKTはお払い箱なのか？ 正直に言うと、私はそれでもいいと思っていました。 TAKTはもともと「AIエージェントのオーケストレーションの感動を伝えたい」という感情だけで作ったシステムです。TAKTでもClaude Codeでも、私が体験している開発プロセスを皆さんに体験してもらえればそれでいい。 私がTAKTを作り始めたのは、エージェントオーケストレーションの可能性に心を奪われたからです。複数のAIエージェントが連携して、まるでチームの

はじめに 以前、AIエージェントが言うことを聞かない問題を解決するために「TAKT」というマルチエージェントオーケストレーションツールを作った話をしました。 TAKT のユーザーコミュニティは以下で質問や要望なとができます。 前回の記事では、taktを使い始めてから世界が変わった話をしました。タスクを投げれば、計画、実装、レビュー、修正のサイクルが自動で回る。これまでの大量の粗悪なコードに向き合う必要がない。3つのプロジェクトを並行して進められるようになった。素晴らしい日々です。 ところが、使い込んでいくうちに、新しい不満が生まれてきました。 taktが安定してきた まずは嬉しい話からしましょう。 TAKTがだいぶ安定してきました。いまの v0.34.0 がいい感じです。日々の開発に使い込んでいるうちに、ワークフローもエージェントも成熟してきて、すごい勢いで開発できるようになってしまいまし

TAKT のユーザーコミュニティはこちら！ 質問や要望などができます！ はじめに 皆さんはAIエージェントと一緒に開発をしていて、こんな経験はないでしょうか。 「さっき言ったことをもう忘れてるの？」 AIエージェントを使った開発は本当に便利です。コードを書いてもらう、リファクタリングを任せる、テストを作ってもらう。素晴らしい時代になったなぁと思います。しかし、使えば使うほど、ある壁にぶつかります。 AIエージェントが、言うことを聞いてくれないのです。 与えた役割を忘れる。共有した知識が抜け落ちる。一度指摘したことを、しばらくしたらまたやらかす。皆さんにも身に覚えがあるのではないでしょうか。 私もまさにこの問題に悩まされてきました。そして、この問題を解決するために「TAKT」というツールを作りました。今回はその経緯と、TAKTが何をしてくれるのかをお話しします。 AIエージェントとの終わりな