0818 | プライバシーメール「Hansel」、AIエンジニア「Omni」、APIハブ「Treg」、Recall.ai新プログラム

葵: Bri RadioのProductHunt Dailyへようこそ。私は葵です。今日は、プライバシー重視のチーム向けのメールサービス、AIエージェントをノートPCからクラウドへ移すツール、それに開発者向けの多彩な新プロダクトをまとめてご紹介します。

悠真: 相棒の悠真です。まずは、GmailやOutlookの代替を目指す「Hansel by Seedling」。データ所有権を重視するチーム向けで、メールはユーザー自身のサーバー上で動くという設計のようです。そこが一番の売りですね。

葵: そして、xpander.aiが公開した「Omni」。AIエージェントの子守りをやめよう、というキャッチコピーで、エージェントを私たちのノートPCからクラウドに移行させるという製品です。

悠真: そのほかにも、APIハブやオープンソースのBlender拡張機能、AIワークジャーナル、それに環境設定ファイルのずれを直すCLIツールなど、開発者向けの面白い作品が今日もProduct Huntに並んでいます。詳しく見ていきましょう。

葵: プライバシーとデータ所有権を重視するチーム向けに作られた、GmailやOutlookの代替となるコミュニケーションサービス「Hansel by Seedling」が登場しています。提供側の説明によると、メールはユーザー自身のサーバー上で動作し、メッセージは端末上で暗号化されるため、プラットフォーム側では読めないとされています。スパムもアーキテクチャレベルで解決され、ユーザーの鍵がなければメッセージは届かない設計です。このサービスは暗号化メッセージ、独自ドメインのメール、カレンダー、ノート、エンタープライズ向け管理ツールを備え、開発者は「どの企業にもロックアウトされない」としています。開発者であるKemone Phillips II氏は、かつてGoogle Workspaceの初期GTMチームに所属していた元Googlerだと自称していますが、先月、GoogleがWorkspaceのサブスクリプションを解約し、警告なしに自分のメールや連絡先などすべてへのアクセスを即時に失ったとコメントしています。その経験から、AIエンジニアリングのパートナーであるBob氏と30日以内にHanselを構築したといいます。ゆ氏はこれを「GmailやOutlookが提供するすべてを、所有権も含めてユーザーに還元する主権的コミュニケーションプラットフォーム」と位置づけ、独自の暗号プロトコル「Wicked Crumbs」を開発したと説明しています。このプロトコルは、ローテーションするアイデンティティ、改ざん検知可能なメッセージチェーン、そしてアーキテクチャレベルでのスパム対策を特徴とし、鍵がなければメッセージは届きません。また、データが自社側に保存されないため、企業によるロックアウトも、データの閲覧も、アカウント解約もできないと主張しています。現時点ではWindows向けにダウンロード提供されており、macOS版とモバイル版は近日対応予定です。コミュニティからは、所有と管理のアイデアへの関心や、「これなら標準的なメールはもう必要ないのでは」という期待の声が寄せられています。ただし、これらは開発者およびコメント投稿者の主張であり、検証済みの成果や第三者評価ではありません。

悠真: なるほど。つまり、企業側が管理できるものの範囲を最初から外しているわけですね。暗号化メッセージに加えて、独自ドメインのメール、カレンダー、ノート、それにエンタープライズ向けの管理ツールも備えていて、「どの企業にもロックアウトされない」と謳っているそうです。そして、この開発者がこのサービスを作ったきっかけが興味深いんです。彼は元Googleの社員だと自称していて、実際に先月、GoogleがWorkspaceのサブスクリプションを解約して、警告なしに、メールや連絡先などすべてへのアクセスを即時に失ったとコメントしているんですよ。

葵: それは相当な体験ですね。自分の仕事の基盤そのものを突然失うという。その経験から、AIエンジニアリングのパートナーと組んで、たった30日でこのサービスを構築したとのことです。彼はこれを、GmailやOutlookが提供するすべてを、所有権も含めてユーザーに還元する、主権的なコミュニケーションプラットフォームと位置づけています。そして独自の暗号プロトコルも開発したそうで、その名も「Wicked Crumbs」。ローテーションするアイデンティティに、改ざんが検知できるメッセージチェーン、それにアーキテクチャレベルでのスパム対策を特徴としているそうです。

悠真: 「Wicked Crumbs」という名前がまた、かなり個性的ですね《chuckle》。この設計の肝は、データが自社側に保存されないので、企業によるロックアウトも、データの閲覧も、アカウント解約も原理的にできない、という主張にあるようです。現時点ではWindows向けにダウンロード提供されていて、macOS版とモバイル版は近日対応予定。コミュニティからは、所有と管理のアイデアへの関心や、「これならもう標準的なメールは必要ないのでは」という期待の声も出ているそうです。

葵: ただ、ここはしっかり押さえておきたいんですが、これらはあくまで開発者本人とコメント投稿者の主張であって、検証済みの成果や、第三者の評価ではありません。特に暗号プロトコルについては、監査や評価を経たものなのかはわかっていない。そういう意味では、興味深い方向性でありつつも、「本当にその通りに動くのか」は今後の検証待ち、と見るのが妥当ですね。この「企業にロックアウトされない」という体験をどう受け止めるか、皆さんもそれぞれの使い方を考えてみてください。

葵: AIエージェントをノートPCの中だけに閉じ込めておくのをやめる、というのが「Omni by xpander」の売りです。xpander.aiが公開したこの製品は「AIエージェントの子守りをやめよう」をキャッチフレーズに、AIエージェントをノートPCからクラウドへ移行させる「AIエンジニア」を謳っています。製品側の説明によると、現状の最良のAIワークフローはユーザーのマシン上のClaudeに閉じていて、ノートPCの蓋を閉じると停止し、自分だけのためにしか動かない、という問題を掲げています。やりたいことを文章で記述するか、自作したものをOmniに持っていくと、Omniがツールとスキルの配線、モックデータでのテストを行い、スケジュール実行・長時間実行・チーム共有が可能なクラウドエージェントとして稼働させます。さらにエージェントの健全性維持として、システムプロンプトの改善、モデルの比較、失敗した実行のデバッグと修正を行います。共同創業者のRan氏は、深夜2時にOpenClawやHermesのトラブルシューティングをしたり、CoworkやClaude Codeが失敗ジョブでトークンを浪費するのを眺めたり、100プロンプトのループに陥ったりした経験がある人向けの製品だと説明しています。Omniは汎用エージェントとして実行するほか、業務プロセス向けのカスタムエージェントも構築でき、コネクタとスキルの配線、システムプロンプトとスケジュールの設定、テストと出荷までを担い、その後はログの読み取り、失敗実行のトラブルシューティング、パフォーマンス最適化、コストと品質に基づくモデルのベンチマークを担当するといいます。初期ユーザーの実際の依頼例としては、モデルのベンチマークやクラウド請求額の監視、毎朝のサインアップ取得などが挙げられています。一方、コミュニティからは「自己修正」がどこまで機能するのか、ターゲットサイトのレイアウト変更時に自動検知・自己修復するのかといった質問も出ています。

悠真: これはあるあるですよね。AIエージェントを動かしていると、自分のPCをずっと起動しておかないといけない。Omniは、やりたいことを文章で記述するか、自分で作ったものを持っていくと、ツールとスキルの配線や、モックデータでのテストを行い、スケジュール実行・長時間実行・チーム共有ができるクラウドエージェントとして動かしてくれるんだそうです。さらに、エージェントの健全性を保つために、システムプロンプトの改善や、モデルの比較、失敗した実行のデバッグと修正までやってくれると。

葵: 共同創業者は、深夜にOpenClawやHermesのトラブルシューティングをしたり、CoworkやClaude codeが失敗ジョブでトークンを浪費するのを眺めたり、100プロンプトのループに陥ったりした経験がある人向けの製品だと説明しています。つまり、エージェントの運用メンテナンスを全部Omniに任せて、子守りはOmniの仕事になる、と。初期ユーザーの実際の依頼例も興味深いですよ。「最新のSonnet、GPT、Qwenモデルでエージェントをベンチマークして、同じ品質で一番安いのを教えて」「クラウド請求額を監視して、スパイクが起きたら原因を調べてSlackに投稿して」「毎朝、昨日のサインアップを取得してエンリッチして、面白いものをチャンネルに送って」、それに「昨夜の実行が失敗したので原因を調べて直して」。ソロユーザーでも動くけれど、マルチプレイヤーでのAIワークを想定していて、エージェントをチームメンバーと共有できるんだそうです。

悠真: ただ、コミュニティからは、この製品の中核的な主張に対する鋭い質問も出ているんです。「自己修正」が実際にどこまで機能して、どこから人間の介入が必要になるのか。質問者は「この手の主張で以前に失望した」とまで言っています。例えば、ターゲットサイトのレイアウトが変わった時、それを自動で検知して自己修復するのか、それとも気づくまで静かに誤ったデータを返し続けるのか。スケジュール実行が人間の判断を要する場面に当たったら、待つのか、誰かに通知するのか、それとも終了するのか。モデルの再比較は、毎回の実行時なのか、失敗時だけなのか、要求時だけなのか。そういった細かい点が並んでいます。

葵: なるほど、確かに「自己修正」という言葉は、実態がどこまでなのかが一番気になるところですよね。その一方で、前向きな評価もあります。クラウドにエージェントを載せる前にモックデータでテストするのは、後々のデバッグ時間を大幅に省けると評価するコメントや、「蓋を閉じると停止する」という表現に共感を示すコメントが出ています。後者は、macOSのcaffeinateと蓋を閉じたスリープを巡る、フォーラムのよくある議論を引き合いに出しているんです。まさに全員が経験しているあの痛み。Omniがその痛みをどう解消するかは、製品の完成度次第、というところですね。

葵: エージェント向けのAPIハブ「Treg」がProduct Huntで「2,600以上のAPIを0%マークアップで使える、ツール向けのOpenRouter」として紹介されています。SEO、ソーシャル、リード、広告、スクレイピングなど2,600以上のツールを、ひとつのURLとひとつのトークンで利用でき、タスクで検索して価格やレスポンスを確認した上で呼び出し、1コール単位で支払う仕組みです。0%マークアップで、オープンソース、具体的にはAGPLで提供され、セルフホストも可能とされています。メーカーのJason氏によると、Tregは社内ツールとして始まったとのことです。発端は、エージェントが実作業に必要なデータが、人間向けに価格設定されたSaaSバンドルに含まれるか、OAuthアプリのセットアップと検証に数日かかるかのどちらかだったという不便さでした。将来はベンダー単位ではなくタスク単位でAPIを選ぶべきだという考えに基づき、約40プロバイダーにわたる2,600以上のエージェント向けツールを提供しています。サブスクリプションはなく従量課金で、サブスクリプションと同じ単価。すでに契約しているプロバイダーはBYOKで使え、その呼び出しはメータリングされないとされます。GoogleやMeta広告、ソーシャル投稿などのOAuth設定も処理し、一度接続すればチームメイトのエージェント全員が利用可能です。コミュニティからは「セットアップに数分、1ドル未満でTikTokとIGの有益なアナリティクスを得られた」という体験が共有される一方、GDPRとEU AI法へのコンプライアンスや、サーバー側で認証情報を注入するプロキシ方式がリクエスト本文をTregのインフラを通過させることから、ログの保存・保持ポリシーについての質問も出ていますが、これらの質問へのメーカー回答はまだ示されていません。

悠真: メーカーの説明によると、これはもともと社内ツールとして始まったものだそうです。きっかけは、エージェントが実作業に必要なキーワードボリュームやバックリンク、広告ライブラリ、データのエンリッチメントといったものが、人間向けに価格設定されたSaaSのバンドルに含まれているか、もしくはOAuthアプリのセットアップと検証に数日かかるか、どちらかだったという、その煩わしさにあったんだとか。将来は、ベンダー単位ではなく、タスク単位でAPIを選ぶべきだ、という考え方に基づいて、およそ40のプロバイダーにわたる2,600以上のエージェント向けツールを提供しているそうです。

葵: サブスクリプションはなく従量課金で、単価はサブスクリプションと同じ。すでに契約しているプロバイダーはBYOK、つまり自分の鍵を持ち込んで使えて、その呼び出しはメータリングされないとのこと。GoogleやMetaの広告、ソーシャル投稿、Business ProfileなどのOAuth設定も処理してくれます。ポイントは、プロキシが実際の上流リクエストを中継して、サーバー側で認証情報を注入する方式だということ。エージェント自体はシークレットを保持しなくて済み、上流APIをモデリングしないので、プロバイダーが変わっても耐えられると説明しています。ただ、これらはすべてメーカーの主張であって、検証済みの結果ではない、という前提は守りたいところです。

悠真: コミュニティの中には実際に使った人の報告もあります。ある投稿者は、セットアップに数分、1ドル未満の費用で、TikTokとInstagramの有益なアナリティクスとベストプラクティスの概要を得られた、と体験を共有しています。別の投稿者は、もう少し大きな視点で、APIやデータプロバイダーが主にエージェントにサービスを提供するようになると、製品発見のプロセス全体が変わっていく、と指摘し、Tregのようなものは基盤モデルやハーネスが本来提供すべきものに思える、という見解を示していますね。

葵: 一方で、未回答の質問も残っているのが正直なところです。GDPRとEU AI法へのコンプライアンス対応を問うコメントがあります。そして、もう一つ鋭い指摘が、このサーバー側で認証情報を注入するプロキシ方式について。OAuthの手間は確かに解決できるけれど、リード・広告・スクレイピングデータなどのリクエストやレスポンスの本文が、Tregのインフラを通過することになる。そこで、ログは本当に残らないのか、ペイロードが一定期間保持されて課金紛争のデバッグに使われることはないのか、と質問しているんです。これらの質問に対するメーカーの回答は、現時点では示されていません。通過するデータの中身が機密性の高いものになりがちなだけに、ここは今後の注目ポイントですね。

葵: 開発者向けの発表です。Recall.aiは会議データから製品を作るアーリーステージ企業向けに「Recall.ai Startup Program」を開始しました。承認されたスタートアップは最初の10,000時間分の録音を、通常よりかなり安い1時間あたり0.25ドルで利用でき、一般顧客と同じ製品とサポートを受けられます。内容にはエンジニアによる直接サポート、高速なボット参加、全録音製品へのアクセス、MCPアクセス、カレンダー統合が含まれ、Zoom、Google Meet、Microsoft Teams、Slackなどに対応しています。同社は自社の説明として、これを「最も信頼性の高い録音インフラ」と表現しています。Recall.aiのMaggie氏は、初期段階のチームが録音インフラをゼロから構築することは想定以上に大きなエンジニアリングプロジェクトになることが多く、それを容易にするためにこのプログラムを開始したと説明しています。プログラムはベータ版ではノートテイキング、インタビュー、ファイナンスなどの分野のチームと実施され、今回より広く開放されました。対象となるのは、ミーティングデータが製品の中核であり、録音された会話を中心に製品を構築するアーリーステージのスタートアップで、プログラムのページによると利用可能地域はグローバルとされています。この発表に対して、あるコメント投稿者は「実際の技術コストを助けてくれる種類のスタートアッププログラムであり、使うかどうか分からない特典を並べるだけではない」と評価し、別の投稿者はローンチを祝福していました。なお、Recall.aiの製品サイトには、同社が3,800万ドルのシリーズB資金調達を実施したとの記載もあります。

悠真: 10,000時間というと、かなり大きいですね。一般の顧客と同じ製品とサポートを受けられる上に、エンジニアによる直接サポートや高速なボット参加、全録音製品へのアクセス、MCPアクセス、カレンダー統合まで含まれると。対応しているのはZoom、Google Meet、Microsoft Teams、Slackと、主要な会議系は揃っていますね。

葵: ええ。Recall.ai側は自社の説明として、これを最も信頼性の高い録音インフラと表現しています。録音・文字起こしのAPI、カレンダー統合、録音のフォームファクターといった機能をまとめて提供する形です。Recall.aiのMaggieさんは、初期段階のチームがこうした録音インフラをゼロから作るのは、想定以上に大きなエンジニアリングプロジェクトになることが多いと説明しています。

悠真: 確かに、会議の録音基盤は一見シンプルに見えて、実際はボットの参加や文字起こしの精度、タイミングの問題など、地味に手間がかかりますからね。ベータ版ではノートテイキングやインタビュー、ファイナンスなどの分野のチームと試した上で、今回より広く開放したとのこと。対象は、ミーティングデータが製品の中核にあって、録音された会話を中心に製品を構築するアーリーステージのスタートアップです。利用地域はグローバルとされています。

葵: コミュニティの反応も見てみると、あるコメント投稿者は、実際の技術コストを助けてくれる種類のプログラムで、使うかどうか分からない特典を並べるだけではない、と評価していました。別の投稿者はローンチを祝福しています。なお、Recall.aiの製品サイトには、同社が3,800万ドルのシリーズB資金調達を実施したとの記載もあります。録音インフラを自前で持つか、こうした提供を活用するかは、初期のチームにとって現実的な判断になりそうです。

悠真: Blenderを使う方に関係する話題です。「Blender Agent Bridge」という無料・オープンソースのBlender拡張機能がProduct Huntに登場しました。MCPを介してBlenderをCodex、Claude、CursorといったAIクライアントに接続し、エージェントがシーンを検査したり、視覚的な証拠を集めたり、ワークフローを支援できるようにする一方、編集、スクリプトの信頼、有料生成の承認はアーティストの管理下に置く設計です。統合例としてMeshy.ai、Tripo3D、Polyhavenなどが挙げられています。開発者は、既存のAIクリエイティブツールは見栄えのするものを生成できても、その下に編集可能なBlenderシーン、モデル、リグ、ワークフローがないというギャップを埋めるために作ったと説明しています。Blenderの知識を置き換えたりアーティストをループから外したりするのではなく、AIアシスタントが実際のBlenderプロセスの中で、シーン検査、ビューポートやレンダー、プレイブラストの証拠収集、構造化ツールの使用、長いワークフローの支援を行い、Blender側が編集、スクリプトの信頼、有料生成の承認、ファイル、認証情報を管理するとしています。現在はパブリックベータとして公開され、実ユーザーやテクニカルアーティスト、MCPベースのワークフロー構築者からのフィードバックを求めています。GitHubリポジトリによると、Blender拡張機能とlocalhost MCPサーバーで構成され、Codex、Claude Desktop、Claude Code、CursorなどMCP対応クライアントが、開いているBlenderシーンの検査、視覚的証拠の収集、可逆的な編集を行い、セッションの信頼を明示的に有効にした場合のみBlender Pythonを実行できます。インストールにはBlender 4.2.0以降が必要で、リリースワークフローはBlender 4.2 LTS、4.5 LTS、5.1で継続的にチェックされています。

葵: ここが肝心なところですが、編集そのものやスクリプトの信頼、有料の生成、承認といった部分は、あくまでアーティストの管理下に置く設計なんですね。開発者はコミュニティ投稿で、既存のAIクリエイティブツールは見栄えのするものを生成できても、その下にある編集可能なBlenderシーンやモデル、リグ、ワークフローが存在しないというギャップを埋めたかった、と説明しています。

悠真: つまり、AIにBlenderの知識を置き換えさせたり、アーティストをループから外したりするのではなく、AIアシスタントが実際のBlenderプロセスの中で働くという位置づけですね。シーン検査、ビューポートやレンダー、プレイブラストによる証拠収集、構造化されたツールの使用、長いワークフローの支援を行い、Blender側が編集とスクリプトの信頼、有料生成の承認、ファイル、認証情報を管理する。今はパブリックベータで公開され、実ユーザーやテクニカルアーティスト、MCPベースのワークフロー構築者からのフィードバックを求めています。

葵: 技術的な構成を少し補足すると、GitHubのリポジトリによれば、Blender拡張機能とlocalhostのMCPサーバーで構成されています。Codex、Claude Desktop、Claude Code、Cursorなど、MCP対応のクライアントが、開いているBlenderシーンの検査や視覚的証拠の収集、可逆的な編集を行い、セッションの信頼を明示的に有効にした場合に限ってBlenderのPythonを実行できる仕組みです。チャットアプリやモデルプロバイダーのキーをBlenderの中に入れずに、シーン認識型のエージェントワークフローを実現するのが主な狙いとされています。

悠真: 読み取り専用の検査でオブジェクトやマテリアル、アニメーション、リグ、カメラ、ノード、レンダー設定、ファイルの健全性を確認できる一方、変更前にはエージェントがビューポートやプレイブラスト、検査レンダー、サムネイルといった証拠を提示してから、可視のコミットとリバートのコントロール付きで可逆的な編集を行う設計ですね。Poly HavenやSketchfab、Tripo、Meshy、ローカルで動くTripoSR、セルフホスト型スタジオのワークフローにも対応し、プロバイダー別に同意と出典管理ができるとされています。インストールにはBlender 4.2.0以降が必要で、リリースは最新のLTS版で継続的にチェックされているようです。

葵: 要するに、AIに生成を任せつつ、最終的な編集と採否はアーティストが握るという境界線を、技術的に丁寧に引いた製品になっているのが特徴ですね。

葵: 最後はオープンソースのAIワークジャーナル「Meridian」です。Product Huntに新しく登場しました。開発者と共同創業者が3ヶ月前に退職して作ったもので、MITライセンス、個人開発者向けに無料、クラウドなし・アカウント不要と説明され、macOS（Apple Silicon、macOS 14以降）とWindows（10/11、64bit）向けに提供されています。AI部分は自分の環境にあるClaude Code、Cursor、Codex CLIを使うか、Groqを無料で使う形です。開発者が語る背景では、以前はClaudeに作業更新を書かせても、会話で伝えたことしか反映されず、その日のうちに解決した想定外の問題が抜け落ちるため、文脈を再構成するのに10分かかっていた。Redditで「開発者はスプリントごとの計画外作業を過小評価している」と投稿したところ話題になったとしています。Meridianはバックグラウンドで動作し、1日をタイムラインにまとめ、開いているJiraやGitHubのチケットと作業を照合して更新文を下書き。1日の終わりには作業ログ、スタンドアップノート、日次サマリーが生成され、承認後にJiraへ投稿できます。サイトではGitHub、Linear、Azure DevOps、Trelloへの対応は「soon（近日）」とされています。データは承認ボタンを押すまで端末の外に出ない、監視ツールではない、というのがメーカーの説明です。コミュニティには、2ヶ月以上ベータ利用しているユーザーの「製品の仕上がりが好き」という声がある一方、Chromeでの作業が自動ログされなかったという報告や、SSH先のリモートVM上の作業を追跡できるか、チームプランの予定、非エンジニアが使えるかといった質問も出ています。批判的な指摘もあり、隣接分野を作っていると明かしたユーザーは、実際のアプリはアカウントが必須に見える、音声・画面収録・アクセシビリティ権限を要求される、LLMへのデータ送信がある中で「プライバシー最優先」という主張は一致しない、などと指摘しています。

悠真: AI部分の使い方が独特ですね。自分の環境にあるClaude Code、Cursor、Codex CLIを使うか、あるいはGroqを無料で使う形とあります。クラウドに依存せず、手元の環境で動かす前提なんですね。

葵: そうですね。開発者が語る背景が興味深くて、以前はClaudeに作業更新を書かせても、会話で伝えたことしか反映されず、その日のうちに解決した想定外の問題が抜け落ちるため、文脈を再構成するのに10分かかっていたそうです。Redditで、開発者はスプリントごとの計画外作業を過小評価しているという投稿が話題になったとも語っています。

悠真: 10分の文脈再構成というのは、開発者なら分かる痛みですね。Meridianはバックグラウンドで動作し、1日をタイムラインにまとめ、開いているJiraやGitHubのチケットと作業を照合して更新文を下書き。1日の終わりには作業ログ、スタンドアップノート、日次サマリーが生成され、承認後にJiraへ投稿できます。

葵: ここが肝心ですが、データは承認ボタンを押すまで端末の外に出ないし、監視ツールではないというのがメーカーの説明です。ただ、GitHubやLinear、Azure DevOps、Trelloへの対応は近日とされており、まだ準備中です。コミュニティの反応は賛否が分かれています。2ヶ月以上ベータ利用しているユーザーからは製品の仕上がりが好きという声がある一方、Chromeでの作業が自動ログされなかったという報告もあります。

悠真: 加えて、SSH先のリモート仮想マシン上の作業を追跡できるか、チームプランの予定はあるか、PMなど非エンジニアが使えるか、という質問も出ています。

葵: そして批判的な指摘もあります。隣接分野を作っていると明かしたユーザーは、実際のアプリはアカウントが必須に見え、音声・画面収録・アクセシビリティ権限を要求され、LLMへのデータ送信がある中でプライバシー最優先という主張は一致しない。アプリストアで第三者による検証もされておらず、オープンソースと言っても自分でビルドしない限り可視性は限られる。ということで、ローンチ説明の一部の主張は実物と合わない、と述べています。

悠真: オンデバイス処理と無料という提案は明確ですが、Chromeでの作業ログ取得範囲、アカウントと権限の扱い、チームプランやリモート仮想マシンへの対応は、現時点では未解決あるいは未回答の問いとして残っている、というのが正直なところですね。

葵: Node.jsプロジェクトで.envと.env.exampleのずれを自動で診断・修正してくれる、依存関係ゼロのCLIツール「envfix」が公開されています。製作者はProduct Huntの投稿で、.env.exampleは更新されたのに誰かのローカルの.envは更新されておらず、アプリがクラッシュして原因特定に時間がかかるという、開発現場で繰り返し直面した問題から作ったと説明しています。小さなチェッカーからNode.jsプロジェクト向けの小さな環境設定ドクターに育ったと述べていますね。検出・修正できるのは、欠落・空・余分・重複した変数、不正な環境宣言、.envがGitで安全に無視・追跡されていない状態などです。.env.exampleの生成と同期にも対応し、ローカルでもCIでも使えます。」

悠真: ずれというのは具体的にどんなものを検出してくれるんでしょう。

葵: 欠落した変数、空の値、余分な変数、重複した変数に加えて、不正な環境宣言なども見つけられます。さらに.envがGitで安全に無視・追跡されていない状態もチェックしてくれます。.env.exampleの生成と同期にも対応していて、ローカルでもCIでも使えるのが特徴です。

悠真: 設計方針にもこだわりがあるみたいですね。製作者は「保守的」と述べていて、既存の非空の値は上書きせず、ログに環境変数の値を出力しないとされています。うっかり秘密情報を流出させない配慮ですね。

葵: コマンド体系は用途ごとに分かれています。checkで.envと.env.exampleを比較し、fixで欠落したキーを.envに追記して、必要ならファイルを作成します。doctorはファイル・構文・整合性・Git安全性のフルヘルスチェック。exampleで.env.exampleを生成し、--syncオプションで新しいキーをexampleに追記して古いものを報告します。

悠真: オプションも豊富ですね。--allでディレクトリ内の全ペアを対象にできますし、--copy-valuesならfix時にexampleから値をコピー、--fill-emptyで既存の空値も埋められます。--dry-runで書き込まずにプレビューもできます。CIを意識した--json出力や、GitHub Actionsのアノテーションの強制オン・オフも用意されています。

葵: READMEの具体例を見ると、checkでは「.envに欠落2件」としてSTRIPEの秘密キーやREDISのURLが挙げられ、「空値1件」としてSMTPのパスワードが報告されています。npx envfix fixを実行すれば、欠落キーが空値で.envに追記されるという流れです。

悠真: doctorの例もありますね。.envと.env.exampleが存在して14変数が設定済み、重複した変数、REDISのURLの欠落、SMTPパスワードの空値が検出され、Git安全性については.envがGitで追跡されておらず、無視されていることも確認されます。このGit安全性の検査は読み取り専用で、依存追加なしにローカルのgitを利用し、.envが無視されていない場合は警告を出すとされています。合計はエラー1件・警告2件でした。

葵: インストール不要で、npx envfixと打つだけで実行できます。GitHubのgokhanozgezer/envfixで、MITライセンスのオープンソースとして公開されています。製作者は、CLI体験と実際のプロジェクトで出会う.envの問題についてフィードバックを募っているそうです。使ってみて気づいたことがあれば、開発者に直接届けられる場ですね。

悠真: いや、今日は本当に盛りだくさんでしたね。 改めて、皆さんに最新の情報をお届けできてうれしく思います。少しでもお役に立てたなら幸いです。 では、今回はこの辺りで締めさせていただきます。最後までお付き合いいただき、ありがとうございました。また次回、お会いしましょう。