0908 | AIが仕事を変える週：エージェント開発からMacの新ツールまで

葵: こんばんは、葵です。

悠真: 悠真です。今週もProduct Huntに並んだ新製品から、使える話題をじっくり拾っていきます。

葵: 今日取り上げるのは、どれも「AIを手元に置いて、でも権限や検証は人間が握る」という線でつながっているものばかりなんです。コーディングエージェントの走らせ方から始まって、その出力をどう読むか、どう保存するか、画面の端に住む小さな道具、分析の自動化、そして取引や創作の道具まで。

悠真: 最初はコーディングエージェントの話からですね。Airuncodeという製品で、複数のコーディングエージェントを自分のマシンで並列に走らせるローカルファーストのランタイムです。

葵: 特徴を整理すると、APIキーは持ち込みで、クラウドモデルとローカルモデルを切り替えられて、プロバイダーに直接払うからトークンの上乗せはゼロ。Windows、macOS、Linuxで動きます。

悠真: ビルダーいわく、「ランタイムを安定した層にして、モデルは交換可能にする」というのが設計思想。ひとつのAI企業、ひとつのサブスク、ひとつのモデルに仕事を依存したくない、という出発点です。

葵: エージェントはコードベースをスキャンして、エージェント間で解決策をディベートさせて、ファイルを編集して、テストを走らせて、失敗したら自動で修復を試みる。さらにV-COREという、Vulkanベースのネイティブ3Dランタイムも同梱していて、ゲーム開発向けにレンダリングや地形や物理の機能を最初からエージェントに使わせられるようにしています。

悠真: ゲーム開発のエンジン機能をいちから作らせない、というのは面白い発想ですね。ただ、注目すべきはコミュニティのコメントで、ひとりのユーザーがかなり核心的な懸念を書いています。

葵: そう、彼が言うには、よくある失敗は「悪いコード」ではなく「リポジトリにすでに存在する実装の、二つ目の正しい実装」だと。各セッションが白紙の状態から始まるから、既存のものがあるか確認せずに書いてしまい、しかもdiffで見ると一見きれいに見える、と。

悠真: で、質問が来ます。このディベートは、全員がすでにコードベースを読み終えたあとに起きるのか、それとも誰も既存実装の有無を確認する前にアプローチを議論しているのか、と。あとは自己修復も、「テストが緑になっても、その修正が正しい層に入ったものかはわからない」と指摘しています。

葵: この懸念は鋭いですね。重複コードの防止が仕様としてどうなっているのか、残念ながら説明からは読み取れない。テストが通ることと、設計上正しい場所を直したこと、は別問題だという指摘で、エージェントを並列に走らせる場合の本質的な難しさを突いています。

悠真: で、この「エージェントが書いたコードを人間がどう検証するか」というテーマ、そのまま次の話につながります。PR Lens by Coldtea.aiというツールです。

葵: こちらはコードベースとプルリクエストごとに、アーキテクチャとデータフローの図をアニメーションで描いてくれる。つまりコードを1行読む前に「変更がどう動くか」が見える、という発想です。

悠真: GitHub Actionとして動かせば、PRを開いた時点で図が付いてくる。CLIでも、コーディングエージェントのスキルとしても使えます。オープンソースでMITライセンス、好きなモデルを持ち込めます。

葵: ビルダーの論理が明確で、「エージェントが毎週どんどんコードを書くが、結局人間が理解しなければならない。1行ずつ読むのはもはや非効率的だ。数百行を毎分眺めて、注意力はシステムのメンタルモデルという重要な部分に残す」と。差分の追加・削除・変更は色分けされて、リクエストがシステムを通っていくのを「見る」わけです。

悠真: エージェントスキルとして使うには「npx skills add coldteadotai/pr-lens」で追加して、「今作った変更を図にして」と頼むだけ。チームでは毎日使っていて、エージェントがPRを出すと図が一緒に届いて、diffを読む前に何が動いたか把握できる、と語っています。

葵: ここでもコミュニティの声が興味深い。ソロ開発者の方が「エージェントのコミットが続くと、自分のコードベースの形が静かに見えなくなっていく。自分が書いた部分はまだ見えるが、指示した部分はそうでもない」と共感していました。

悠真: その方は質問もしていて、特定の変更ではなく「今あるシステムの全体を眺められるのか」、そして言語境界をまたげるのか。Rustのコマンドと、その反対側のTypeScriptの呼び出し元をつなげられるのか、それとも図は言語ごとに分かれるのか、と。

葵: ほかにも、設定やインフラ系の変更はロジック変更と「形」が違うから描画が意味のある形になるのか、という指摘、そもそもLLMの知能で図を作っているのか、ハードコードされた処理なのか、という信頼性の質問もありました。この点はまだ答えが確定していない、ということですね。

悠真: で、ここから視点を変えまして、エージェントやAIとのやり取りそのものを、どう保存し、どう手元に置くかという話に移ります。ふたつ並べてみましょう。まずClipnote。

葵: Clipnoteは、ChatGPTやClaudeの会話がタブを閉じた瞬間に消えてしまう、という問題への解決策です。AIに「保存して」と一言言うだけでその場で残る。貼り付けて入れることももちろんできます。

悠真: ビルダーの動機がリアルで、「AIで作ったコード断片や下書きやアイデアが、チャットウィンドウのあちこちに散らばって、保存も整理も共有も簡単にできない」から作った、と。MarkdownやHTMLなどに対応して、コレクションに整理して、共有リンクで公開もできる。MCP経由でチャットから直接、あるいはWebアプリから手動で。

葵: 機能面は具体性があって、保存したクリップをタイトルで検索、既存クリップの本文を読み込ませて回答に使わせる、会話の続きで新しいクリップを作る、既存のものを「書き換えて」と更新すると旧内容は自動でバージョン保存される。削除しても30日間はゴミ箱から復元できる。

悠真: HTML対応なのが意外に効くところで、ChatGPTに「割り勘ツールを作って」「じゃんけんゲームを作って」と頼むと動くHTMLが出てくるから、それをブラウザにコピペして終わり、ではなく保存してURLで開ける。資料や議事録から、ちょっとした便利ツールまで残せるわけです。

葵: コミュニティのコメントで大事な点がふたつ。ひとつは「保存して」のMCPフローがコピー&ペーストより摩擦が低くて賢い、という評価。もうひとつは共有リンクへの警戒で、「保存しておいたものは半分未完成だったり、公開したくないものを含んでいたりする。リンクに有効期限やアクセス制御はあるのか、それともURLを知っていれば誰でも開けるのか」という質問です。

悠真: 別の方は、MCP保存がデフォルトで非公開なのは正しい判断で、「初日に誤ってリークする事故を防いでいる」と述べています。公開設定はPrivateとPublicから選べてあとから切り替えられる、とサイトにありますが、期限の話は解決していないですね。

葵: 同じテーマのもうひとつがTucky。こちらはmacOSのネイティブノートアプリで、画面端に細い一本の帯として眠っている。マウスを寄せるとノートのタイトルが扇状に広がって、選ぶと開く、という挙動です。

悠真: ビルダーは創業者で、「散らばるメモ、アイデア、フィードバックに溺れていた。良い製品は捕まえた思考から始まるのに、自分のは失われていった」と語っています。ローカルで暗号化、Apple SiliconとIntelの両対応で約15MB、自己更新。

葵: AIエージェントはPlusプラン、月12ドルで。音声ディクテーションが60言語以上、Gmail、Googleカレンダー、Docs、Sheets、GitHub、Notionのコネクタ。Alt+Spaceでどのアプリからでも尋ねられて、Cmd+Jで「このノートについて」聞ける。ノートのタイトルは常に質問に使われますが、本文はユーザーが許可したときだけ読まれる設計です。

悠真: 無料プランはノート1つだけ、AIも音声もコネクタもなし。ここへの指摘が手厳しくて、「多くの機能が課金の裏にあるので、Tuckyが何をできるのか味わう前に支払う必要がある。無料プランを切って最初から有料を推した方がよかったのでは」という質問が上がっていました。

葵: もうひとつの質問も境界の問題で、「ローカルで暗号化といいながらPlusは最高のLLMモデルを使う。その境界はどこか。クラウドモデルは明示的に尋ねたときだけ呼ばれるのか、それともバックグラウンドでノートを読んで行動を提案するのか」と。このへん、Clipnoteの公開リンク問題と同じ、「便利さと守りの境界線」の話ですね。

悠真: あとWindows版の要望が複数のコメントで寄せられていました。ここで方向転換して、画面に住む小さな道具の話をふたつ。ノッチを使うアシスタントです。

葵: まずAssist。Macのノッチから動く、三つの機能が合体したツールです。Optionキーを押しながら画面に描いて、声で説明する。ローカルのWhisperKitが文字起こしして、注釈付きスクリーンショットとその意図がセットで保存される。

悠真: ビルダーの出発点が具体的で、ネイティブのスクリーンショット機能で切り抜いて画像をCodexに送る、長いプロンプトをタイプする。この流れを1日100回やると辛くなる、と。収録元によればAssistは2週間前に作られたそうです。

葵: その他の機能は、Control+Optionで全画面のクリーンなスクリーンショットが即座に保存されて、ノッチの下にクイックエディタが出てきて、トリミング、ぼかし、背景や影を付けたスタイル編集ができる。クリップボード履歴もノッチの横にあって、テキストと画像をフィルタして、ワンクリックで再利用。削除も個別にできる。

悠真: プライバシーがかなり徹底していて、音声はクラウドに送られない。WhisperKitでローカル文字起こしで、生の音声は文字起こしが終わるまでメモリにあるだけで保存されない、サーバーは存在しない。スクリーンショットをOCRして解釈することもない。$20の買い切りで1台、サブスクなし。

葵: コミュニティからは、カーポートトンネル症候群を持つ方から「これは本当に助かる」という声があった一方、鋭い批判もありました。「クリップボード履歴を保持するマネージャーは、そう設計しなくても機密情報の保管庫になる。誰もがAPIキーやパスワードをマネージャーから貼り付ける瞬間があって、それがノッチに再利用可能な形で置かれる。検出して除外するのか、保持期間を設定できるのか」と。

悠真: これは確かに、Clipnoteの共有リンク問題と同じ構造です。「保存は便利、でも何を保存しているか考える」という設計の落とし穴。見た目も用途も違うのに、三つの話が一つの線でつながる。

葵: もう一つがRemind。会議開始の瞬間に、全画面のリマインダーを出すMacアプリです。メニューバーで常駐して、GoogleかMicrosoftのカレンダーに接続。会議の時間になると全画面を取って、AIブリーフィングとワンクリック参加ボタンを提示する。

悠真: ビルダーの動機は「深く集中していると気づいたら次のZoomに7分遅刻していた」ということ。ブリーフィングは会議相手の情報に、メール、Slack、Notionの関連文脈を足したもので、サンプルを見ると、相手が先週求めたSOC 2の詳細とロールアウトの時間軸がまだ送られていないこと、Slackでチームがどう扱っているか、予算の担当者が前回年間契約を強く求めたこと、までが要約されていた。

葵: ブリーフィングは事前に研究されていて、Claude、OpenAI、Gemini、Grokの自分のAPIキーを使う。Zoom、Teams、Google Meet、Webexに対応。時間ぴったりに画面全体を奪うから、時計を見ながら仕事しなくていい、という設計思想です。価格は年19.99ドル、7日間のトライアル付き。

悠真: 続いて、仕事の自動化です。DataboxのRoutines。AIアナリストにプロンプトとスケジュールを与えると、ライブデータに対して毎回分析とレポートを実行して、メール、Slack、アプリ内に配信する機能です。

葵: Databoxはもともとアナリティクスプラットフォームで、まずAI Analyst Genieで質問に即答するようにして、次のArtifactsで答えを polished な共有レポートに変えた。でもどちらも「人がチャットを開いて尋ねる」ことが起点。Routinesはその繰り返し作業をスケジュールに乗せる、という流れです。

悠真: 具体的な使い方がいくつか挙がっていて、月曜に毎回手作業で作っていた週次監視レポートを、ペイド広告の分析ルーティンにした人が「毎朝9時にSlackに届く。同じ接続データから作られているから送る前に二重確認する必要がない」と語っています。

葵: 便利な細部がふたつあって、既存のチャットやArtifactをワンクリックでRoutineに変換できる。プロンプトを書き直す必要がない。そして全ての実行がRoutineの中に保存されて検索可能で、「先週火曜日のチェックは何と言っていたか」をチャット履歴を遡って探す必要がない。

悠真: トリガーも柔軟で、スケジュールのほかにWebhookでも発火できる。キャンペーンが終わった瞬間やしきい値を超えた瞬間に動くので、イベント駆動の自動化を自分で組まずに済む。実行は毎回ライブの接続データから引くから、キャッシュされた古い答えを信じ込むことがない、というのがユーザーの信頼の理由でした。

葵: cronとの対比が良い質問でしたね。cronはタイマーでスクリプトを走らせるだけで、毎回同じ種類の分析を出す。Routineは毎回「何を伝える価値があるか」を判断して、違う分析を毎回する。だから自律的に分析を任せられる、という擁護の仕方です。

悠真: でも、オープンな問いが残ります。「毎回ダッシュボードをチェックせずに済むのはいい。でもどのインサイトを伝える価値ありと判断しているのか、その判断基準はどうなっているのか」という質問です。これは明示的な答えが取れたままではありませんね。

葵: そして思想面では、「分析は道具を操作するものではなく、自分のビジネスを理解するセマンティックデータレイヤーの上で動くエージェントになる」という賭けを表明しています。そしてこの「判断をエージェントに任せるが、実行の権限は人間に残す」という設計、次のNinaでさらに明確になります。

悠真: Nina by Antalpha。上場企業Antalpha、NASDAQのANTAの非托管AIトレーディングアシスタントです。ここでのキーワードは「非托管」。

葵: ビルダーの説明が率直です。トレーディングの大変な部分は取引そのものではなく、その前の全部だ、と。タブが10個開いて、オンチェーンのフロー、スマートマネーのウォレット、マクロ、センチメント。しかも汎用チャットボットはリアルタイムデータがないから間違ったことを言う。で、「AIエージェント」と称するものはウォレットの管理権を求めてくるか、独自トークンで動く。数分を節約するために鍵をボットに渡すのは価値に合わない、と。

悠真: だからNinaはルールを一つに絞りました。Ninaは絶対にユーザーの資金を持たない。全ての取引はユーザー自身のウォレットで署名する。Ninaは機関グレードのリアルタイムオンチェーンデータを読んで、結論を先に出し、壁のようなテキストではなくチャートで答える。取引したいときは最適ルートのドラフトを作って、署名は自分でする。

葵: スマートマネーの追跡、市場とイベントの予測、Polymarket、ウォレットの安全診断、Sentinelという常時アラート、MCP対応で既存のAIクライアントからデータを引ける。最近はひとつのチャットで暗号資産と米国株をカバーするように広がっています。

悠真: 興味深いのはビルダーの俯瞰で、「自律的な『何でも屋エージェント』の夢を捨てて、信頼できるアナリストとドラフターという一つの役割に絞った。作るうちにスコープはむしろ狭くなった」と。ここがAiruncodeやDataboxと同じ、判断の自動化と、実行や署名の権限を分ける思想です。

葵: コミュニティでは非托管を評価する声が複数あって、「非托管が鍵だ、みんな同じように見るべきだ」という方もいました。逆に、市場分析が米国株だけなのか他の地域も選べるのか、非米国市場への拡大の予定はあるのか、という質問も残っていて、これは未解決です。

悠真: 最後は視点を変えて、創作の道具をふたつ。まずScriptly。iOSのテレプロンプターで、話す速度に合わせてスクロールする「音声追従」が特徴です。

葵: ビルダーはコンテンツクリエイターで、「従来のプロンプターはあらかじめ設定した固定のスクロール速度に話すペースを合わせる必要があって、それが辛かった。ネイティブで速くて直感的な、書いて、整理して、収録する、一つのアプリで完結するものが欲しかった」と。

悠真: 機能は、音声追従のテレプロンプター、スクリプトの執筆と整理が一箇所に、Apple Watchで録画の開始停止やテキスト調整ができる、ストレージはローカルのみ。アカウント登録も不要。現在TestFlightでパブリックベータ中です。

葵: コミュニティからは皮肉で実用的な指摘がひとつ、「ビデオサービスなのに、Product Huntにデモビデオを上げていない」と。そして真剣な質問が、Androidユーザーから。テレプロンプターが常に弱いリンクで、固定速度スクロールだとテキストを追いかけたり途中で止まったりするから、音声追従こそが解決策だとしつつ、「Androidはロードマップにあるのか、音声マッチングはiOSのAPIに依存しているのか。そして脱稿して一文話したら、戻ってきたときに続きから拾うのか、最後の行で待つのか」と。

悠真: この「脱稿したあとの挙動」の質問、音声追従プロンプターの実用性を左右する重要な点で、残念ながら答えはまだ得られていません。

葵: もうひとつがBloop。Macの音楽ビジュアライザーで、システムオーディオかマイク入力を8種類のリアルタイムシェーダースキンで可視化します。ミニプレーヤーとして他のアプリの上に常時、メニューバーにも出せて、MP3のプレイリストを入れると動画として書き出せる。Apple Siliconのみ、ノータライズ済み、サブスクなし。2つのスキン、GlossyとContourは無料で、トライアルではなくアプリ全体が使えます。

悠真: ビルダーの動機が良いんですよ。「昔のiTunesビジュアライザーが欲しかった。でも画面で綺麗なだけでなく、最後にファイルを手渡してくれるものを」。音楽を公開している人は、画面に何かを出すものが必要だから、という事情ですね。

葵: 制作の苦労話が印象的です。時間がかかったのはオーディオ処理ではなく、ひとつのスキンを「生きている」感じにすることで、流れるインク、有機的な波、256点のばね結合リングが外に押し出されて緩和される、というのを4回作り直した。最後に攻撃的な音に反応するようにした。で、名前を変えた、と。Black Holeと呼んでいたけど、画面の動きは名前と正反対で、何も引き込まれずに輪郭が押し出されて足跡を残す。だからWakeに改名した。

悠真: 400行くらいの部分に、アプリ制作で学んだことの大半が詰まっていたという話で、この手のインタビューでは貴重な正直さです。コミュニティからは「落ち着いたスキンはBGM向け、Wakeのような激しいのはビートの強い曲向け、という使い分けになるのでは、実際の利用データで検証されるか」という考察、要望は色の追加とApple TV版がありました。

葵: このBloopとScriptly、あと今日の全員に共通する点を振り返ると、どれも「手元のデバイスで完結するローカルファースト」という設計でしたね。AiruncodeもAssistもTuckyもBloopも、データやモデルをできるだけ自分のマシンに置く。

悠真: 一方で、共有や自動化で便利さを出す部分には、毎回同じ疑問が寄せられていました。Clipnoteの共有リンク、Assistのクリップボード履歴、Tuckyのクラウドモデルがノートをどこまで読むか。つまりAI時代のツールは「どこまで手元に置き、どこから外に出すか」の境界線の設計が、本質的な勝負所だということですね。

葵: 今日のどの製品も、その境界線を意図的に決めてきたビルダーの姿勢が見えました。すべての記述はビルダーやユーザーの申告に基づくもので、実際の性能や結果は検証されていない点は押さえておいてください。

悠真: それでは今日はこのへんで。聞いてくれてありがとうございました。また来週。