http://izanami.dev/occupations/Programmer Programmer に関連する記事のRSSフィードです Sun, 14 Jun 2026 05:43:19 GMT https://validator.w3.org/feed/docs/rss2.html izanami RSS Feed ja http://izanami.dev/favicon.ico http://izanami.dev/occupations/Programmer All rights reserved 2026 http://izanami.dev/post/b3bca470-48a6-44db-9a3e-bdea379d5b1d http://izanami.dev/post/b3bca470-48a6-44db-9a3e-bdea379d5b1d今野颯太 Tue, 09 Jun 2026 13:55:44 GMT http://izanami.dev/post/73d6ab8f-e05e-4f30-9b7e-ea492055ae79 http://izanami.dev/post/73d6ab8f-e05e-4f30-9b7e-ea492055ae79今野颯太 Mon, 01 Jun 2026 00:20:13 GMT http://izanami.dev/post/dd01ed8b-245c-448d-8b7f-6658b14e3e5f http://izanami.dev/post/dd01ed8b-245c-448d-8b7f-6658b14e3e5f今野颯太 Mon, 01 Jun 2026 00:16:34 GMT http://izanami.dev/post/a0d4b872-d47a-4427-b93a-ce3ce8e62ae7 http://izanami.dev/post/a0d4b872-d47a-4427-b93a-ce3ce8e62ae7今野颯太 Fri, 29 May 2026 18:19:25 GMT http://izanami.dev/post/6f7e401a-79aa-4f4e-9b8a-dfededc821d3 http://izanami.dev/post/6f7e401a-79aa-4f4e-9b8a-dfededc821d3今野颯太 Fri, 29 May 2026 00:11:18 GMT http://izanami.dev/post/8a73e51a-bf1a-4462-a5ae-4937901f24af http://izanami.dev/post/8a73e51a-bf1a-4462-a5ae-4937901f24af今野颯太 Thu, 28 May 2026 23:50:03 GMT http://izanami.dev/post/6e541028-b5e4-4e96-aef1-9783a8ff2a4a http://izanami.dev/post/6e541028-b5e4-4e96-aef1-9783a8ff2a4a今野颯太 Sat, 23 May 2026 14:02:56 GMT http://izanami.dev/post/8711b64c-6b3e-4dd6-b9a7-8edcb1543ebf http://izanami.dev/post/8711b64c-6b3e-4dd6-b9a7-8edcb1543ebf中村達郎 Wed, 20 May 2026 18:35:58 GMT http://izanami.dev/post/3ff237aa-9de2-4eba-8476-deb9dc9a07f3 http://izanami.dev/post/3ff237aa-9de2-4eba-8476-deb9dc9a07f3ロク Wed, 06 May 2026 09:09:45 GMT ※ 現時点では正式な運用実績や定量データは未確定のため、具体的な数値効果は今後の利用状況に応じて更新する想定です。 VRCardMakerが目指す将来像 VRCardMakerは、現在はVRChat向けプロフィールカードを作成・保存・出力できるWebアプリとして開発されています。 一方で、このプロジェクトの最終目標は、ローカルで完結するカードメーカーに留まりません。 今後は、現在のIndexedDBによるローカル保存から、クラウド保存に対応していく予定です。これにより、端末をまたいだ利用や、継続的なプロフィール管理、バックアップ性の向上が実現しやすくなります。さらにその先では、保存したプロフィールをクラウド上で公開し、他のユーザーが見つけたり、共有したり、交流のきっかけにできる仕組みへ発展していく構想があります。 つまりVRCardMakerは、次のような段階で成長していくプロジェクトです。 1. 作る VRChat向けプロフィールカードをブラウザで手軽に作成する 2. 保存する 作成したカードを継続的に管理し、再編集できるようにする 3. 公開する クラウド上にプロフィールを保存し、共有可能にする 4. つながる 公開プロフィールを起点に、ユーザー同士が交流できる場へ広げる このため、VRCardMakerは現在の時点では「プロフィールカード作成ツール」ですが、将来的にはプロフィール公開と交流を支えるプラットフォームとして育っていくことを前提にしています。 作成ツールとしての手軽さと、サービスとしての広がり。その両方を見据えていることが、このプロジェクトの大きな特徴です。 まとめ VRCardMakerは、VRChatユーザー向けに、自己紹介や交流のきっかけづくりに使えるプロフィールカードを簡単に作成できるWebアプリです。 現在は、ブラウザ上でカードを作成し、編集し、IndexedDBに保存し、PNGとして出力できるところまでを中心機能としています。これにより、画像編集ソフトがなくても、継続的に使えるプロフィールカード制作体験を実現します。 そして将来的には、クラウド保存、公開プロフィール、共有導線へ対応し、最終的にはプロフィールを通じてさまざまな人がつながれる交流プラットフォームへと発展していく構想があります。 いまは土台を固めるフェーズですが、その先には「作る」だけで終わらないサービスとしての広がりがあります。VRCardMakerは、VRChatユーザーの自己表現を支えながら、将来的には交流の入口そのものをつくっていくプロジェクトです。 よくある質問 Q: VRCardMakerはすぐに使い始められますか？ A: はい。VRCardMakerはWebアプリとして利用でき、基本的にはブラウザからすぐに使い始められます。現時点ではアカウント登録を前提とせず、ローカル環境でプロフィールカードを作成・編集・保存できる構成です。そのため、まずは試しにカードを作ってみたい方でも、比較的スムーズに導入できます。 Q: 保存したプロフィールカードはどこに保存されますか？ A: 現在のVRCardMakerでは、作成したプロフィールカードはブラウザのIndexedDBに保存されます。そのため、同じブラウザ・同じ端末環境であれば、あとから再度開いて編集することができます。将来的にはクラウド保存への対応を予定しており、複数端末での利用や公開機能へ発展していくことを想定しています。 Q: モバイルでも利用できますか？ A: VRCardMakerはWebアプリとして利用できるため、モバイルブラウザからの利用も視野に入れています。ただし、現時点では主にカード作成・編集・出力の基本体験を整備している段階のため、利用環境によっては操作性や出力時の挙動に差が出る可能性があります。今後の改善を進めながら、より幅広い環境で使いやすい体験を目指しています。 Q: 将来的にクラウド保存や公開プロフィールには対応しますか？ A: はい。VRCardMakerは現在、ローカル保存を中心としたプロフィールカード作成Webアプリとして開発を進めていますが、将来的にはクラウド保存への対応を予定しています。さらにその先では、作成したプロフィールを公開・共有できる仕組みを整え、プロフィールを通じてさまざまなユーザー同士がつながれる交流プラットフォームへ発展していくことを目指しています。]]> http://izanami.dev/post/73b20467-323c-42d9-9706-a72b812ad5ea http://izanami.dev/post/73b20467-323c-42d9-9706-a72b812ad5ea中村達郎 Tue, 28 Apr 2026 15:06:53 GMT http://izanami.dev/post/b2e6708e-3a70-4410-8e28-92b91ba07cc3 http://izanami.dev/post/b2e6708e-3a70-4410-8e28-92b91ba07cc3山本和康（ハーモニコム） Fri, 10 Apr 2026 20:49:54 GMT http://izanami.dev/post/6f88da3b-4127-4f74-893d-7c8c953764d8 http://izanami.dev/post/6f88da3b-4127-4f74-893d-7c8c953764d8Tomoyuki Naito Fri, 10 Apr 2026 09:12:08 GMT http://izanami.dev/post/371ea4b6-ae38-4aae-a756-2c6b26c1ccbf http://izanami.dev/post/371ea4b6-ae38-4aae-a756-2c6b26c1ccbfTomoyuki Naito Sat, 28 Mar 2026 19:33:01 GMT http://izanami.dev/post/7bf49c3b-9d53-4a8a-8e21-7bb04bc53dd8 http://izanami.dev/post/7bf49c3b-9d53-4a8a-8e21-7bb04bc53dd8小島正裕 Wed, 18 Feb 2026 23:35:58 GMT http://izanami.dev/post/e32c9419-7a91-4383-bc03-23aa8ccef4b8 http://izanami.dev/post/e32c9419-7a91-4383-bc03-23aa8ccef4b8山本和康（ハーモニコム） Tue, 17 Feb 2026 21:03:37 GMT http://izanami.dev/post/92993519-379f-40e6-a178-06d71db254dc http://izanami.dev/post/92993519-379f-40e6-a178-06d71db254dc山本和康（ハーモニコム） Tue, 17 Feb 2026 20:39:06 GMT http://izanami.dev/post/2241ae65-eeec-48ff-9cd2-ce60b8503319 http://izanami.dev/post/2241ae65-eeec-48ff-9cd2-ce60b8503319保科亮太郎 Wed, 14 Jan 2026 03:57:06 GMT http://izanami.dev/post/81e2ab6c-195e-494f-89e0-3dde04241a6a http://izanami.dev/post/81e2ab6c-195e-494f-89e0-3dde04241a6a川滿優太 Tue, 06 Jan 2026 17:33:57 GMT http://izanami.dev/post/cd7be4dc-3b23-49b6-85e3-a0d4f7b9adab http://izanami.dev/post/cd7be4dc-3b23-49b6-85e3-a0d4f7b9adabHub YoRu Wed, 31 Dec 2025 01:39:32 GMT - 「日本語で」って言ったのに、突然流暢な英語でまくし立ててくる > - 「その書き方は禁止！」と叫んだ10秒後に、同じ書き方で納品してくる > - 編集に失敗してエラーまみれなのに、「完了しました（ドヤッ）」と報告してくる 「前も言ったよね、ルール守れないの？」と画面にツッコミを入れる日々。 今回は、この「ちょっと物忘れの激しい天才」との付き合い方を改善すべく、僕が試行錯誤しているメモとなります。 制御の鍵「Customizations」の構造 Antigravity を制御する Customizations には、設定場所（Global/Workspace）と設定内容（Rules/Workflows）の組み合わせで4つの顔があります。  ここで重要なのは、これらが対等ではないということです。彼らの中には明確な 「ヒエラルキー（優先順位）」が存在します。 ルール強制力のピラミッド Antigravity の行動原理は、驚くほど「中央集権的」です。 公式ドキュメントや検証結果から推測されるパワーバランスは以下の通り。 | 優先度 | 設定タイプ | 性質 | イメージ | | :--- | :--- | :--- | :--- | | 0 | Core Policies | Google による安全・基本原則 | 国の「憲法（絶対不可侵）」 | | 1 | Global-Rules | ユーザー全体の共通規約 | 企業の「全社規定（Workspace を凌駕）」 | | 2 | Workspace-Rules | プロジェクト独自の規約 | 部署ごとの「ローカルルール」 | | 3 | Global-Workflows | 共通のタスク手順 | 社内標準の「作業マニュアル」 | | 4 | Workspace-Workflows | 個別タスクの直接指示 | 現場での「作業指示書」 | ご覧の通り、Global（全体設定）が Workspace（個別設定）を上書きする設計になっています。 つまり、「このプロジェクトだけは日本語で」と Workspace でどれだけ叫んでも、上位の Global 側に「標準は英語」といった強いニュアンスが残っていれば、現場の訴えは無視される可能性が出てきます。 「Rules」と「Workflows」の決定的な違い そもそも、この2つは AI への「届き方」が根本的に違います。 - Rules: AI の「OS」や「性格」を定義するシステム・インストラクションです。常に背後で流れている「空気」のような存在ですが、階層が高いため、ここで矛盾が生じると AI は深刻な混乱に陥ります。 - Workflows: 特定の コマンドで発動する「具体的なタスク命令」です。AI の注意（Attention）を一時的に強く引きますが、本質的には Rules という絶対的な土俵の上で踊っているに過ぎません。 なぜ「日本語ルール」はあっさり無視されるのか？ ここには、設定の階層だけでは説明がつかない「2つの見えない壁」が存在します。 1. 内部的な「英語バイアス」の壁 Antigravity（Gemini）は多言語を理解しますが、その思考のコアは英語ベースで最適化されています。 特に「命令を絶対に守る」というタスクにおいて、日本語での指示は英語に比べて「解釈の揺れ」が生じやすく、優先度の低い「付加情報」として切り捨てられる傾向があります。つまり、日本語で書くこと自体が、AI にとっての「ルールの強制力」を弱めてしまう要因になり得るのです。 2. Core Policy という絶対君主 僕たちが触れる設定よりさらに深い場所に、Google が定義した「AI としての基本行動原則（Core Policy）」が潜んでいます。 ここに「回答は常に標準的かつ汎用的な形式で行う」といった指示がある場合、末端の Workspace で「日本語で！」と叫んでも、AI は「憲法（Core Policy）」を優先し、最も安定した出力言語である英語に回帰してしまいます。 結論：本丸（Global Rules）を「英語」で統治せよ この物忘れの激しい天才を、こちらの土俵に引き止めるための最も効率的なアプローチ。 それは、「最も高い階層（Global Rules）に、彼らの母国語（英語）で『Respond in Japanese』と刻み込むこと」です。 もちろん、Workspace で日本語を使ってはいけない、ということではありません。 ただ、言語設定のような「絶対に譲れない根幹のルール」については、下位の Workspace で都度お願いするよりも、上位の Global で強制力を高めておく方が、AI の注意力が散漫にならずに済みます。 イメージとしてはこんな使い分けです： Global Rules (in English) AI に絶対的なルールを強いる英語命令です。 - （常に日本語で返せ） - （簡潔に答えろ） - （謝罪するな） Workspace Rules (in Japanese) こちらは現場レベルの具体的なディレクション。馴染みのある日本語で OK です。 - 「このプロジェクトでは Riverpod を使用して状態管理を行うこと」 - 「スネークケースではなくキャメルケースを徹底すること」 具体的な設定 Antigravity の Customizations は、JSON ではなく Markdown（.md）ファイル で記述します。 それぞれのファイルは以下の形式で作成し、適切なディレクトリに配置することで機能します。 1. Global Rules 配置場所: Global Rules には設定用の UI メニューが存在しません。 そのため、AI に対して「常時有効なルール」であることを明示するには、ファイル冒頭に属性を直接記述する必要があります。 2. Workspace Rules2. Workspace Rules 配置場所: UI 上の Activation Mode でモードが選べます | モード名 | 定義 | Frontmatter (記述例) | | :--- | :--- | :--- | | Always On | 常に適用されるルール。AI の基本動作の固定に最適。 | | | Manual | ユーザーがチャット内で指定した時のみ適用される。 | | | Model Decision | AI が必要と判断した時のみ参照される。コンテキスト節約に有効。 | | | Glob | 特定のファイル形式（拡張子等）のみに適用される。 | | 一応 Content にも同じ Mode に書き換えてください。（少し効果あるらしい） flutterlints 3. Global Workflows 配置場所: どのプロジェクトでも "/コマンド" で呼び出せる汎用的なタスク手順です。 「この書き方は全てのコードで共通」というリファクタリングルールや、README 生成などをここに置いておくと、プロジェクトごとに Workflow を作り直す必要がなくなります。 ※Workflows はコマンド起動型のため、Activation Mode の設定は不要です。 ${selectedCode} 4. Workspace Workflows 配置場所: そのプロジェクト独自の技術スタックに依存する手順です。 Workflows は / コマンドで呼び出す「手順書」です。 Rules とは異なり、Activation Mode の UI 項目および activation プロパティは存在しません ${selectedCode} 役割を明確にする。精度を最大化するための特化型 Workflow Global Rules で基本的な性格を定義したら、次は「具体的なタスクごとの役割」を Workflow（コマンド）として整理していきましょう。 AIのポテンシャルを最大限に引き出すコツは、一つのチャットであれこれ頼みすぎないことです。 「実装」と「検証」の役割を分けることで、AIの注意力が分散するのを防ぎ、アウトプットの精度を劇的に向上させることができます。 ここでは、僕が実際に現場で活用している「役割別・運用ルール」のサンプルをご紹介します。ポイントは、「憶測（〜のはずだ）」を避け、徹底して「事実（コードや実行結果）」に基づいた回答を求める仕組みにすることです。 1. 実装特化型： 説明は最小限。とにかく「動くコード」を最優先で提案してもらう、実装担当としての窓口です。 ${selectedCode} 2. 批判的思考型： 「git diff」という客観的な事実に基づき、ロジカルに改善点を指摘してもらうレビュー窓口です。 git diff.agent/rules/ 3. 執拗なテスト実行型： コマンドの実行結果（Exit Code）という「確実な証拠」を元に、検証を行うテスト窓口です。 flutter test integrationtest/apptest.dart 「なんとなく使う」から「仕組みで使いこなす」へ。 こうして窓口（コマンド）を分け、それぞれに「事実に基づいた判断」を求めるルールを定義することで、AIはより頼もしいパートナーになってくれます。 最後に 公式ドキュメントにも特に書いていないので正解はわかりません。 果たして彼を最高の相棒に変える決定打になるのか。期待と不安を混ぜつつ、現在も絶賛検証中です。]]> http://izanami.dev/post/5c932467-4031-4bea-a845-f0ae0fb7e1a9 http://izanami.dev/post/5c932467-4031-4bea-a845-f0ae0fb7e1a9Hub YoRu Thu, 18 Dec 2025 14:56:49 GMT 救いだったこと > アップデートのたびに約250人ほどの方が確実に更新してくれています。 > 「毎日開きはしないけど、スマホの片隅に置いてくれている」。 > 生活の一部に潜り込めたのなら、作った身としては「結果オーライ」と前向きに捉えています。 収益化の反省：後手に回ったサブスク設計 当初は広告収益のみを想定していましたが、「開かれないアプリ」に広告は無力でした。 直面した課題：アクティブ率が下がると、広告露出が極端に減る。 迅速な判断：急遽「音声入力」や「デバイス間同期」を追加し、サブスクプランを構築。 「シンプルさ」と「収益性」の両立。 最初からこの出口を想定して設計しておくべきだったというのが、リリースから1ヶ月経った今の率直な反省です。 これからの『Today!!』 この1ヶ月間の試行錯誤を経て、一つ確信したのは「シンプルで利便性がある」という方向性自体は間違っていないということです。 今後のアップデートでは、むやみに機能を増やしません。 「時計に予定を表示する」というコア体験を磨くために、見た目のカスタマイズ性や、使い心地の改善に注力しようと思います。 「あれもこれもできる」ではなく、「これだけは、どのアプリより使いやすい」。 そんな一歩先を目指して、また一歩ずつコードを書いていきます。 Build-in-public（公開開発）は賛否両論ありますが、無名の個人開発者が広告費を使わずここまで多くの方に届けられたのは、このスタイルのおかげです。挑戦して本当によかったと思います。]]>