<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/">
    <channel>
        <title>Web Designer に関連するフィード</title>
        <link>http://izanami.dev/occupations/Web Designer</link>
        <description>Web Designer に関連する記事のRSSフィードです</description>
        <lastBuildDate>Tue, 12 May 2026 23:42:35 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>izanami RSS Feed</generator>
        <language>ja</language>
        <image>
            <title>Web Designer に関連するフィード</title>
            <url>http://izanami.dev/favicon.ico</url>
            <link>http://izanami.dev/occupations/Web Designer</link>
        </image>
        <copyright>All rights reserved 2026</copyright>
        <item>
            <title><![CDATA[カップルアプリ&仲が深まる質問：Riamo]]></title>
            <link>http://izanami.dev/post/29575ba8-f978-4cd0-9673-e74c985dbf1b</link>
            <guid>http://izanami.dev/post/29575ba8-f978-4cd0-9673-e74c985dbf1b</guid><dc:creator>すきだよ</dc:creator>
            <pubDate>Sat, 31 Jan 2026 19:09:47 GMT</pubDate>
            <description><![CDATA[AIカップルアプリ「Riamo」とは


Riamo(リアモ)は恋人・夫婦向けのカップルアプリ。毎日の質問、やりたいことリスト、記念日リマインド、仲が深まる診断機能がこのアプリ1つで完結！楽しく交流で]]></description>
            <content:encoded><![CDATA[AIカップルアプリ「Riamo」とは


Riamo(リアモ)は恋人・夫婦向けのカップルアプリ。毎日の質問、やりたいことリスト、記念日リマインド、仲が深まる診断機能がこのアプリ1つで完結！楽しく交流できます。

▼ App Store (iOS)：

https://apps.apple.com/us/app/riamo-couple-relationship/id6744003738

▼ Google Play (Android)：

https://play.google.com/store/apps/details?id=app.product.sukidayo

主な特徴


- 恋人・夫婦に必要な機能がオールインワン
- かわいい動物がふたりに仲が深まる質問をお届け
- やりたいことリストで未来の話ができる
- 記念日・誕生日リマインドで大切な日を忘れない
- カップル診断でテーマ別にふたりの価値観をAIが分析
- 4ヶ国語対応。国際恋愛・国際結婚中のパートナーにもおすすめ

こんな方におすすめ

- お互いのことを知りたい付き合いたてのカップル
- 離れていてもお互いを感じていたい遠距離カップル
- 大事なことを話し合いたいこれから結婚するカップル
- 忙しくてもすれ違いたくない共働き夫婦に

主要機能

![画像の説明を入れてください](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/1f3eb862-4367-4296-b5a1-09f45305cb4c/c3a80d8f-e6e0-4732-9566-c28bb281c081.png)
やりたいことリスト
「これ一緒にやりたいね」って話していたことや、「ふたりでやりたい！」とふと思いついたことを、気軽に書き留めることのできる機能です。コメントもできるので予定を立てるのもスムーズです。

記念日・誕生日リマインド
記念日や誕生日を、Riamoがそっと教えてくれるので、大切な日を忘れてすれ違うことがありません。「覚えていてくれた」が、ふたりの関係を少し深める一日に。

一問一答
毎日、かわいい動物キャラが「ふたりの仲を深める質問」をお届け。ふたりの交際ステータスや年齢に合わせて、「来月一緒にやりたいことは？」など、会話のきっかけを届けてくれます。

カップル診断
テーマ別に相互理解を深める機能で、「お金の使い方」「愛情表現」「コミュニケーションタイプ」といった価値観のテーマに回答すると、AIが「ふたりの共通点」「関係性をよりよくするヒント」のフィードバックをしてくれます。

思い出の共有
毎月届く質問に答えるだけで、その月の出来事や気持ちを写真と一緒に自然に振り返れます。大切な瞬間が、ふたりだけのアルバムとして残っていきます。


ユーザーの声（Apple Storeから引用）


⭐️⭐️⭐️⭐️⭐️
付き合いたてから熟年夫婦までおすすめ出来る
遠距離中の彼氏と使ってます。こういうのは面倒くさがってあまり続かない彼氏なのですが珍しく、質問に答えて続いています。あまりに素晴らしいアプリなので正規版だと思ってました。正規版がリリースされたらβ版から引き継げない可能性があると注釈があったのですが、本当に素晴らしいアプリなので頑張って引き継げるようになって欲しいです！

⭐️⭐️⭐️⭐️⭐️
子どものいる夫婦こそ利用してほしいアプリです
自分たち夫婦の間には幼い子どもがいるのですが、どうしても子どものことばかり考えて、普段の会話も子どもの話ばかりしがちです。それが悪いことではないのですが、夫婦ふたりの仲をより良いものにしていく時間を、なかなか取れていないなと思いました。そんな中このアプリは、その時間を上手に作ってくれます。このアプリをきっかけに、夫婦2人のお互いを思いやった会話が生まれます。キャラクターや部屋の空間もかわいくて好きです。家具が増えるのも嬉しいですね。これからも夫婦共に利用させてもらいます。

⭐️⭐️⭐️⭐️⭐️
遠距離の彼女と愛用中。

彼女と遠距離恋愛中で、なかなか電話する時間も取れず、気づけばすれ違いばかり…。そんな時にこのアプリを見つけました。日々届く質問のおかげで自然と会話のきっかけができて、「今日の質問楽しかったよね！」と話題にできるのがとても嬉しいです。普段は照れて言えないことも答えやすく、お互いの新しい一面を知ることができました。今ではすっかりふたりのお気に入りアプリになっています！

⭐️⭐️⭐️⭐️⭐️
干渉しすぎない
遠距離恋愛期間、利用を始めました。義務的なタスクというより、日課にできる距離感がとても良いと感じています。生活時間の異なる互いのスケジュールの中で、午前に回答し昼や夜に話題に出すと、Riamoが生活の一部や仲をとり持つ仲介役として寄り添ってくれているような気がします。トピックの１つになるだけでなく、お互いの理解度を測ったり、パートナーの情報を新しく取り入れたりできるため、利用してからの仲の深まりを一層感じました。休日には、カップル診断や最近取り入れられたアルバム機能で、同棲に向けた軽い相談もできました。


よくある質問

Q: どうやったら始められますか？

A: 
招待する側はサインイン後、「新しくはじめる」を押してプロフィールを登録して、パートナーに招待コードを送信します。招待された側が「招待コードで始める」からプロフィール登録とオンボーディングを完了すると、決まった時間に二人に質問が届くようになります。

Q: 質問が届く時間は変更できますか？

A: 誘った側の人（招待コードを送ったの人）のみ変更可能です。1時間刻みで設定が可能で、誘った側の設定がふたりで共有されます。メニュー > 設定 > 基本設定 > 質問の配信時間 から変更できます。

Q: 機種変更などでデータを引き継ぐにはどうしたらいいですか？

A: 引き継ぎ元のRiamoで使用しているアカウントと、同じアカウントでログインすることで、データを引き継いだ状態でRiamoを再開いただくことができます。「Googleでサインイン」をご利用の場合は、引き継ぎ元・先で同一のGoogleアカウントで、「Appleでサインイン」をご利用の場合は、引き継ぎ元・先で同一のAppleIDでサインインをお願いいたします。

※異なるアカウントを使用した場合は、別アカウントとして新規利用となりますのでご注意ください。

Q: 対応している言語はなんですか？

A: 現在、日本語・英語・韓国語・スペイン語に対応しています。


]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Stamp it]]></title>
            <link>http://izanami.dev/post/fde1ed40-7598-44a8-bf25-7a7f8ca4deb2</link>
            <guid>http://izanami.dev/post/fde1ed40-7598-44a8-bf25-7a7f8ca4deb2</guid><dc:creator>Rey Kuroi</dc:creator>
            <pubDate>Thu, 29 Jan 2026 22:13:08 GMT</pubDate>
            <description><![CDATA[「Stamp it」は、写真にロゴや著作権マーク（ウォーターマーク）を
驚くほど簡単に追加できる画像加工アプリです。 
複雑な編集機能はあえて省き、
「透かしを入れて作品を守る」ことだけに特化しました]]></description>
            <content:encoded><![CDATA[「Stamp it」は、写真にロゴや著作権マーク（ウォーターマーク）を
驚くほど簡単に追加できる画像加工アプリです。 
複雑な編集機能はあえて省き、
「透かしを入れて作品を守る」ことだけに特化しました。

【こんな人におすすめ】
- イラストや写真をSNSに投稿するクリエイター
- 作品の無断転載を防ぎたい方 
- 自分のブランドロゴをおしゃれに入れてシェアしたい方

【主な機能】
- 直感的な操作
指2本でピンチするだけで、透かしの拡大・縮小・回転が自由自在。好きな場所にスッと配置できます。

- 選べる透かし（プリセット＆カスタム） 
すぐに使えるプリセットを内蔵。もちろん、カメラロールからご自身のオリジナルロゴ画像を読み込んで使うことも可能です。

- 高画質保存
大切な作品だからこそ、画質にはこだわりました。
元の写真の解像度を維持したまま、クリアに保存します。

- 色変更機能
プリセットの透かしは、写真の雰囲気に合わせて好きな色にカラーチェンジが可能。どんな写真にも馴染みます。

あなたの作品を守る「最後の仕上げ」を、Stamp itで。]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[おくすりもういいかい]]></title>
            <link>http://izanami.dev/post/8fbc7ad1-04c6-48ad-93c5-4b42b27fcb9d</link>
            <guid>http://izanami.dev/post/8fbc7ad1-04c6-48ad-93c5-4b42b27fcb9d</guid><dc:creator>Rey Kuroi</dc:creator>
            <pubDate>Thu, 29 Jan 2026 21:55:56 GMT</pubDate>
            <description><![CDATA[【「いつ飲んだっけ？」をなくす。一番シンプルな服用記録】



「おくすりもういいよ」は、頭痛薬や胃薬といった
頓服薬、サプリメントなどの
「決まった時間ではなく、間隔をあけて飲む」ものの管理に特化し]]></description>
            <content:encoded><![CDATA[【「いつ飲んだっけ？」をなくす。一番シンプルな服用記録】



「おくすりもういいよ」は、頭痛薬や胃薬といった
頓服薬、サプリメントなどの
「決まった時間ではなく、間隔をあけて飲む」ものの管理に特化した記録アプリです。

難しい設定は一切ありません。 
飲んだ時にボタンを押すだけで、次のタイミングまでをカウントダウン。 
時間が来たら、かくれんぼの合図のように「もういいよ！」と優しくお知らせします。

■ こんな方におすすめ
- 「最後に飲んだのは何時だっけ？」と毎回記憶を辿っている方
- 薬の間隔（4時間あける、6時間あける等）を計算するのが面倒な方
- 通院時、医師に正確な服用状況や症状を伝えたい方
- 事務的なリマインダーではなく、少し癒やされるアプリを使いたい方

■ 主な機能


- ワンタップ記録: 飲んだ瞬間に「今飲んだ」を押すだけ。
- 次までカウントダウン: 次に飲める時間をリアルタイムに表示。
- 優しい通知: 薬という言葉を使わず「もういいよ！」とだけお知らせ。
- 診察用レポート: 曜日や時間帯ごとの傾向をヒートマップで可視化。
- 詳細ログとメモ: 服用時の症状などを50文字以内のメモで残せます。
- プライバシー配慮: 記録データは端末内（iCloud）のみに保存されます。

あなたの体調管理を、もっとシンプルに、もっと心地よく。 
「おくすりもういいよ」が、あなたのペースを優しく守ります。]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Gemini 3 Pro × Cursor が最強な理由]]></title>
            <link>http://izanami.dev/post/3fde74cd-e2d2-4b04-9d6e-2fc4a3274eb9</link>
            <guid>http://izanami.dev/post/3fde74cd-e2d2-4b04-9d6e-2fc4a3274eb9</guid><dc:creator>Nexyl</dc:creator>
            <pubDate>Wed, 19 Nov 2025 09:37:28 GMT</pubDate>
            <description><![CDATA[Gemini 3 Pro が Cursor に来たのはかなり大きい

実際に Cursor のモデル選択に Gemini 3 Pro が追加されたため、この記事では開発現場での使い勝手を中心にまとめる]]></description>
            <content:encoded><![CDATA[Gemini 3 Pro が Cursor に来たのはかなり大きい

実際に Cursor のモデル選択に Gemini 3 Pro が追加されたため、この記事では開発現場での使い勝手を中心にまとめる

https://x.com/cursorai/status/1990814174264381910

ただ「何がどう良いのか」は用途によって違うので、重要ポイントだけきれいに整理するよ

https://cloud.google.com/blog/ja/products/ai-machine-learning/gemini-3-is-available-for-enterprise/


公式ブログから読み解く Gemini 3 Pro の背景

Google 公式ブログでは、Gemini 3 の進化ポイントとして
推論力、文脈把握力、マルチモーダル理解、ツール利用能力、エージェント性能
の 5 つが大きく強化されたと説明されている。

特に CEO の Sundar Pichai 氏はこう述べている。

> “Gemini 3 is our most intelligent model, built to grasp depth and nuance… much better at figuring out the context and intent behind your request, so you get what you need with less prompting.”

これは、この記事でまとめている「長時間の対話でも文脈が安定する」「複雑な指示の理解が強い」という Gemini 3 Pro の実務的な強みと完全に一致している。

DeepMind チームの公式発表でも次のように説明されている。

> “Gemini 3 Pro significantly outperforms 2.5 Pro on every major AI benchmark… delivering state-of-the-art reasoning and multimodal understanding.”

実際に Gemini 3 Pro は、LMArena、SWE-bench Verified、MMMU-Pro、Video-MMMU などで最高水準のスコアを記録しており、これは本記事で紹介する 「コード解析・画像理解が強い」 というポイントの裏付けになっている。

さらに、Google は Gemini 3 を Cursor / GitHub / JetBrains / Replit などサードパーティ IDE へ即日提供 したと明言している。

> “Gemini 3 is available today in third-party platforms like Cursor, GitHub, JetBrains, Manus, Replit and more.”

この記事で紹介する「Cursor で Gemini 3 Pro を使うメリット」は、これらの 公式情報に基づいた実務視点の解説 になっている。


コーディング作業での文脈保持が強い

![画像の説明を入れてください](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/711ab4a6-151e-4f23-935f-4ac41f39f356/453d7d78-c40c-44ac-ac26-d4315afd7768.png)

Cursor で Gemini 3 Pro モデルが使えるようになっていた

Gemini 3 Pro の最大の強みは、超ロングコンテキストに対応してること

なお、公式ブログでは Gemini 3 Pro の推論性能・マルチモーダル性能・コード生成能力について詳しいベンチマークと使用例が紹介されている。

https://blog.google/products/gemini/gemini-3/responsible-development

これが Cursor との相性で抜群に効いてくる

大規模なリファクタリングをやるとき、複数ファイルを跨いで修正していく場面があるやん

Claude（Sonnet）でも長い対話に強いけれど、タスクによっては途中で文脈の保持が不安定になることがある。

Gemini 3 Pro は非常に長いコンテキストに対応していて、長時間の対話でも比較的安定して文脈を保持しやすい。

設計書とコードを同時に参照しながら、何往復もやり取りするような作業でも安定してる

例えば、API の仕様書を読み込ませて「この仕様に沿って実装を修正して」って依頼したとき、その仕様を最後まで覚えててくれるのが地味に助かる

長時間の対話が必要な複雑なタスクほど、この文脈保持力が効いてくるよ

リサーチ寄りのタスクが速い

Gemini 系は「調査系の質問への回答」や「情報整理・統合」が得意な傾向がある。

これは Gemini の得意領域やな

エラーメッセージをそのまま投げて「これ何が原因？」って聞いたとき、Gemini は学習済みの知識を総合して説明してくれるので、実務で求める調査・比較の流れを自然に補完してくれる。

ライブラリ選定で「Next.js で状態管理するなら何がいい？」って聞いたら、一般的に知られている特徴や設計思想を踏まえて、使い分けを整理して比較してくれる。

特に「外部知識とコードを混ぜた説明」が上手で、理論と実践を繋げて教えてくれるから理解しやすい

新しい技術を学ぶときとか、知らないライブラリに触れるときに Gemini に聞くと、学習効率がめっちゃ上がるよ

コードの解釈力が高い

Gemini は元々コード理解能力が強いモデルとして設計されてる

これが Cursor で効いてくるのは、既存コードを読む場面やな

レガシーコードベースに入って「このコード何してるん？」ってなったとき、Gemini に読ませると意図まで説明してくれる

コードから設計意図を推測するのが得意で、「このロジックは Strategy パターン的な構造」などの判断もしてくれる場合がある

複雑なロジックの読み解きも強い

例えば、再帰処理が絡んだアルゴリズムとか、複雑な状態管理のコードとか、一見しただけじゃ理解しづらいコードでも、Gemini は丁寧に分解して説明してくれる

既存仕様の読み取りも正確で、「この API はどういう仕様で動いてるん？」って聞いたら、コードから仕様を逆算して説明してくれるから、ドキュメントがない古いプロジェクトでもめっちゃ助かる

こういう「読む力」が強いから、引き継ぎ案件とか、他人のコードを理解する場面で Gemini は頼りになるよ

画像付きのデバッグ能力が高い

画像理解精度は現行の大規模モデルの中でも高いレベルにある。

UI のスクリーンショット、PDF の図解、システムの構成図、エラー画面のキャプチャ、こういうのを読み取る力が非常に強いんよね

これが Cursor に統合されることで、画像からコード提案してもらうフローがめちゃくちゃ強化される

例えば、デザインのモックアップを見せて「これをコンポーネント化して」って依頼したら、画像から UI の構造を読み取って、ちゃんと動くコンポーネントを生成してくれる

PDF の技術仕様書とか、図解が多いドキュメントを読ませて「この図の通りに実装して」って言っても、ちゃんと理解して実装してくれるから、視覚的な資料からコードへの変換がスムーズなんよ

エラー画面のスクショを投げて「これ直して」って言うだけでも、画面から状況を把握して原因を特定してくれるから、説明する手間が省ける

UI 開発とか、デザインからコードに落とし込む作業が多い人にとっては、この画像理解能力はかなりのアドバンテージやな

モデル切替による最適化が可能になる

Cursor では複数のモデルを使い分けられるようになってる

Gemini 3 Pro が加わることで、モデルの役割分担がハッキリできるようになったんよね

例えば、こんな感じで使い分けられる

泥臭いデバッグや既存コードの解析は Gemini に任せる

一般的な傾向としては

- 既存コードの解析やデバッグは Gemini
- 抽象設計や文章化は Claude
- 実装のスピードは GPT または Claude

という使い分けがしやすい。

こういう風に、タスクの性質に合わせてモデルを切り替えることで、それぞれの強みを最大限に活かせるようになる

Gemini 3 Pro が加わったことで、Cursor が「万能 IDE AI」として完成度が一気に上がったと感じてる

モデルごとの得意分野を理解して使い分けるだけで、開発効率がめちゃくちゃ変わるよ

コストパフォーマンスが高い

Gemini は大量のコンテキストを扱う割にコストが低めに設定されてる

Gemini は大量コンテキストの割に API 単価が抑えめなので、Cursor と組み合わせても比較的コストを気にせず使いやすい

長時間の対話や、大量のコードを読ませる作業が多い人にとっては、このコスパの良さは無視できない

Claude だとコンテキストが長くなるほどコストが跳ね上がるけど、Gemini ならそこまで気にせず使えるから、気軽に大規模なコードベースを読ませられる

特に、プロトタイプ段階とか、試行錯誤が多いフェーズでは、コストを気にせず何度も聞き直せるのがありがたい

開発の初期段階で色々試したいときとか、学習目的で使いたいときに、Gemini はめっちゃ使いやすいよ

実際の使い分けパターン

ここまでの話を踏まえて、実際にどう使い分けるかを具体的に整理するね

まず、新規プロジェクトの立ち上げフェーズやと、設計や構造を考える部分は Claude に任せる

Claude はアーキテクチャ設計とか、コンポーネント設計とか、抽象的な思考が得意やからな

で、実装フェーズに入ったら、ガンガンコードを書く部分は GPT か Claude に任せる

スピード感が大事な場面では、このあたりのモデルが強い

既存コードのリファクタリングとか、レガシーコードの理解が必要な場面では Gemini を使う

コードを読む力と、長い文脈を保持する力が活きてくるからな

デバッグ作業では、エラーメッセージを投げて調査してもらうのは Gemini が得意

リサーチ力と情報統合力が効いてくる

UI 開発で、デザインからコンポーネントを生成する場面でも Gemini が活躍する

画像理解能力が高いから、モックアップから直接コードを生成してもらえるんよね

ドキュメント作成では、技術仕様書とか API ドキュメントみたいな構造化された文章は Claude に任せる

読みやすい文章を書く力は Claude が強いからな

こんな感じで、フェーズやタスクに応じてモデルを切り替えることで、それぞれの強みを引き出せるよ

Cursor での設定方法

Gemini 3 Pro を Cursor で使うための設定も簡単やから、ここで軽く触れとくね

Cursor の設定画面から、モデルの選択肢に Gemini 3 Pro が追加されてるから、そこから選ぶだけ

API キーの設定が必要な場合もあるけど、基本的には Google の AI Studio でキーを取得して、Cursor の設定に貼り付けるだけ

あとは、Cursor の Composer とか Chat 機能で、モデルを切り替えながら使えるようになる

デフォルトモデルを Gemini にするか、タスクごとに切り替えるかは好みやけど、自分は基本的にタスクごとに切り替えてる

理由は、さっき話した通り、モデルごとの得意分野が明確やから、適材適所で使った方が効率がいいんよね

設定自体は 5 分もかからんから、まだ試してない人はぜひ試してみてほしい

Gemini 3 Pro の弱点も知っておこう

ここまで Gemini のメリットばかり話してきたけど、弱点も知っとかんとフェアじゃないよな

Gemini は事実ベースの処理が得意な分、クリエイティブ生成や抽象的な文章化では Claude の方が自然な表現を出す場面が多い

例えば、技術ブログの記事を書いてもらうとか、ユーザー向けのドキュメントを作ってもらうとかは、Claude の方が自然で読みやすい文章を書いてくれる

あと、Gemini は事実ベースの情報処理が得意な分、推測や創造が必要な場面では保守的になりがちやな

「こういう設計にしたらどう？」って提案を求めるより、「この設計の問題点を指摘して」って聞く方が得意

だから、アイデア出しとか、ブレインストーミング的な使い方は Claude の方が向いてる

実装フェーズでは GPT が高速に返す場面も多い

Gemini は正確性を重視する分、慎重になる傾向があるんよね

こういう弱点を理解した上で、適材適所で使い分けるのが一番賢いやり方やと思う

今後の展望

Gemini 3 Pro の登場で、AI アシスタントを使った開発の幅がめちゃくちゃ広がった

今後は、さらに多くのモデルが Cursor に統合されていく可能性が高いし、モデル間の連携とか、自動切り替えみたいな機能も出てくるかもしれん

例えば、タスクの性質を自動判定して、最適なモデルを提案してくれる機能とか、複数のモデルを同時に使って回答の質を高める機能とか、そういう進化が期待できる

Gemini 自体も進化し続けてるから、今後のアップデートでさらに性能が上がっていくはず

特に、コード生成の精度とか、推論能力の向上とか、そのあたりが強化されたら、Cursor での開発体験がさらに良くなるよな

AI アシスタントを使った開発は、まだまだ発展途上やけど、Gemini 3 Pro の登場で一つの大きな節目を迎えたと感じてる

まとめ

Gemini 3 Pro が Cursor に統合されたことで、開発環境が一気に進化した

超ロングコンテキストでの文脈保持力、リサーチと情報統合力、コードの解釈力、画像理解能力、そしてコストパフォーマンス

この 5 つの強みが、Cursor での開発体験を大きく変えてくれる

特に、情報の統合力と長文処理能力は、複雑なプロジェクトや大規模なコードベースを扱う人にとって、めちゃくちゃ価値がある

Claude や GPT と使い分けることで、それぞれのモデルの強みを引き出せるから、Cursor がまさに「万能 IDE AI」として機能するようになったんよね

実際に使ってみると分かるけど、モデルごとの得意分野を理解して使い分けるだけで、開発のスピードと質が段違いに変わる

まだ Gemini 3 Pro を試してない人は、ぜひ一度使ってみてほしい

特に、既存コードの理解とか、長時間の対話が必要なタスクで使ってみると、その強さが実感できるはず

最初は Claude や GPT との違いが分かりにくいかもしれんけど、使い込んでいくうちに「あ、このタスクは Gemini の方が得意やな」って感覚が掴めてくる

モデルの使い分けを意識するだけで、開発効率が大きく変わるから、試してみる価値は十分ある
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Amazon が放った新兵器「Kiro」が開発体験を変える]]></title>
            <link>http://izanami.dev/post/0070ea5b-3012-46a6-877b-df5bedbabc9a</link>
            <guid>http://izanami.dev/post/0070ea5b-3012-46a6-877b-df5bedbabc9a</guid><dc:creator>Nexyl</dc:creator>
            <pubDate>Sun, 09 Nov 2025 10:29:07 GMT</pubDate>
            <description><![CDATA[Kiro って何やねん

2025 年 7 月 14 日、Amazon が突如として発表した新しい開発ツールがある。その名も「Kiro」や。これは単なる AI コーディングアシスタントやなくて、AI ]]></description>
            <content:encoded><![CDATA[Kiro って何やねん

2025 年 7 月 14 日、Amazon が突如として発表した新しい開発ツールがある。その名も「Kiro」や。これは単なる AI コーディングアシスタントやなくて、AI エージェントが自律的に動いてプロジェクトを完成させていく、めっちゃ革新的な IDE なんよね。

GitHub Copilot や Cursor みたいなツールは、コードを書くときにサジェストしてくれるけど、Kiro は全然違うアプローチを取ってる。開発者が自然言語で要件を説明したら、Kiro が勝手にユーザーストーリー、受け入れ基準、技術設計ドキュメント、そして実装タスクのリストまで作ってくれるんやで。

ワイが最初にこれを知ったとき、「また新しいツールかよ」って思ったんやけど、調べてみたらこれがマジでヤバいんよ。従来の「vibe coding」（なんとなくコードを書いていくスタイル）から、ちゃんと設計されたスペック駆動の開発に移行させようとしてるのが見えてくる。


Amazon が投じた新たな挑戦

Kiro を発表したのは、Nikhil Swaminathan（プロダクトリード）と Deepak Singh（VP of DevEx & Agents）や。彼らが目指してるのは、開発者がプロトタイプから本番環境まで一貫した体験で開発できる環境なんよね。

興味深いのは、Kiro は AWS のサービスやないってこと。Code OSS プラットフォーム（つまり VS Code のベース）の上に構築されてて、どんなクラウドプロバイダーでも使えるように設計されてる。サンプルでは AWS の統合が紹介されてるけど、実際には技術スタックに依存せずに動くんや。

これって Amazon にとってもめっちゃ大きな賭けやと思うんよね。AWS に縛り付けるんやなくて、開発者体験そのものを向上させることに焦点を当ててる。それが結果的に AWS の利用増加につながると信じてるんやろな。


スペック駆動開発という考え方

Kiro の最大の特徴が「スペック駆動開発」や。これがどういうことかっていうと、まず開発者が自然言語で「こういう機能が欲しい」って説明するんよ。そうすると Kiro が以下のものを自動生成してくれる。

- ユーザーストーリーと受け入れ基準
- 技術設計ドキュメント
- 実装タスクのリスト

これってめっちゃ重要で、特にチームで開発してるときに威力を発揮するんよね。みんなが「なんとなく」で進めるんやなくて、明確な仕様書があって、それに基づいて実装していける。

ワイも個人開発してるとき、勢いでコード書き始めて後で「あれ、これ何やりたかったんやっけ？」ってなること多いんやけど、Kiro ならそういうカオスな状況を避けられるんよ。

従来のツールって「コードを書くのを助ける」ってところで止まってたんやけど、Kiro は「何を作るべきか」から「どう作るか」まで一貫してサポートしてくれる。これが本当の意味での開発支援やと思うんよね。


AI エージェントの自律性がヤバい

Kiro のもう一つのヤバいポイントが、AI エージェントの自律性や。これは単なるアシスタントやなくて、バックグラウンドで勝手に動いてタスクを完了させていくんよ。

例えば、ワイがコード書いてる間に、AI エージェントが以下のことをやってくれる。

- ドキュメントの更新
- テストコードの生成
- ボイラープレートコードの作成
- コードレビューのチェック

これって「経験豊富な開発者が隣で見守ってくれてる」感じに近いんよね。ワイが見落としてることをエージェントが拾ってくれるし、面倒な作業は勝手にやっといてくれる。

使用されるモデルは Claude Sonnet 4 がメインで、これは高度なコーディングと推論に強いモデルや。もしくは「Auto」モードを選べば、タスクに応じて複数の最先端モデルを使い分けてくれるんやで。

自律的に動くエージェントって聞くと「暴走しないん？」って心配になるかもしれんけど、Kiro はちゃんとイベント駆動で動くから、開発者がコントロールできる範囲で動作するんよね。


Hooks でバックグラウンド作業を自動化

Kiro の Hooks 機能がマジで便利そうなんよ。これはファイルの保存、作成、削除といったイベントをトリガーにして、エージェントがバックグラウンドでタスクを実行してくれる仕組みや。

具体的にどんなことができるかっていうと、

- ファイル保存時に自動的にリンターを実行
- 新しいコンポーネント作成時にテストファイルも自動生成
- コミット前にコードフォーマットと型チェック
- ドキュメントの自動更新

これってワイらが普段「やらなきゃいけないけど面倒くさい」って思ってる作業を、全部自動化してくれるってことなんよね。

特にチーム開発だと、コードレビューで「リンター通してください」「テスト書いてください」みたいなやり取りが減るから、レビューの質が上がると思うんよ。本質的な設計やロジックのレビューに集中できるようになる。

Hooks は手動でもトリガーできるから、「今このタイミングでドキュメント更新してほしい」みたいな使い方もできる。柔軟性がめっちゃ高いんよね。


使えるモデルと技術スタック

Kiro で選べるモデルは主に 2 つや。

Claude Sonnet 4 を選べば、信頼性の高い高度なコーディングと推論が可能になる。これは複雑なロジックや設計判断が必要なときに強いんよね。

一方で Auto モードを選べば、タスクに応じて複数の最先端モデルを使い分けてくれる。簡単なタスクには軽量なモデル、難しいタスクには強力なモデルって感じで、コストと性能のバランスを自動で調整してくれるんや。

技術スタックに関しては、Kiro は本当に柔軟や。AWS のサービスとの統合例が多く紹介されてるけど、実際には、

- 任意のクラウドプロバイダー（AWS、Azure、GCP など）
- 任意のフレームワーク（React、Vue、Next.js など）
- 任意のバックエンド（Node.js、Python、Go など）

全部使える。これは Code OSS ベースで作られてるおかげで、既存の VS Code エクステンションもそのまま使えるんよ。

ワイみたいに複数のプロジェクトで違うスタック使ってる人間にとって、これはめっちゃありがたいんよね。ツールを切り替える必要がなくて、Kiro 一つで全部対応できる。


料金プランと展望

現在 Kiro はプレビュー期間中で、完全無料で使えるんよ。これはマジでチャンスやと思う。早めに触っておけば、将来的に有料化されたときもスムーズに移行できるし、フィードバックも反映されやすいからね。

将来的には 3 つの料金プランが予定されてる。

無料プラン

- 月 50 回のエージェントインタラクション
- 個人の小規模プロジェクトなら十分使える

Pro プラン（月額 19 ドル）

- 月 1,000 回のエージェントインタラクション
- 本格的な開発をする人向け

Pro+ プラン（月額 39 ドル）

- 月 3,000 回のエージェントインタラクション
- ヘビーユーザーやチーム開発向け

この価格設定を見ると、GitHub Copilot（月額 10 ドル）や Cursor（月額 20 ドル）と比べてそこまで高くないんよね。むしろ提供される価値を考えると、めっちゃコスパいいと思う。

エージェントインタラクションの「1 回」が具体的にどういう単位なのかは気になるところやけど、おそらく一連のタスク実行を 1 回としてカウントするんやろな。


GitHub Copilot や Cursor との違い

Kiro を理解する上で、既存のツールとの違いを知っておくのは大事や。

GitHub Copilot は基本的にコード補完ツールや。コードを書いてる最中に次の行を提案してくれるし、コメントから関数を生成してくれたりする。けど、プロジェクト全体の設計とかドキュメント生成までは面倒見てくれへん。

Cursor はもうちょっと進んでて、AI とチャットしながらコードを書いていける。ファイル全体を編集したり、複数ファイルにまたがる変更も提案してくれる。けど、やっぱり「コードを書く」ところに焦点が当たってるんよね。

Kiro はそれらとは全然違うレイヤーで勝負してる。スペックを書くところから始まって、設計、実装、テスト、ドキュメントまで一貫してサポートしてくれる。しかも AI エージェントがバックグラウンドで自律的に動いてくれるから、開発者は本質的な部分に集中できるんや。

GeekWire の記事で「vibe coding の混沌を終わらせる」って表現されてたけど、まさにそれなんよね。勢いでコード書いてくカオスな開発から、ちゃんと設計された秩序ある開発への移行を目指してる。

これは競合というより、開発フローそのものを変えようとしてるツールやと思うんよ。


実際の開発フローはどう変わるん？

Kiro を使った開発フローがどうなるか、想像してみよか。

まず、新機能を追加したいとき、ワイは自然言語で要件を説明する。

「ユーザーがプロフィール画像をアップロードできる機能が欲しい。画像は S3 にアップロードして、サムネイルも自動生成したい」

そうすると Kiro が、

- ユーザーストーリー（ユーザーとして、プロフィール画像をアップロードしたい、なぜなら…）
- 受け入れ基準（画像形式は JPEG/PNG、最大サイズは 5MB、など）
- 技術設計（フロントエンドのコンポーネント、API エンドポイント、S3 設定、サムネイル生成ロジック）
- タスクリスト（UI コンポーネント作成、API 実装、S3 設定、テスト作成、など）

これ全部を生成してくれる。

で、ワイが実装を始めると、Hooks が動いて、

- ファイル保存時に自動フォーマット
- コンポーネント作成時にテストファイルも自動生成
- コミット前に型チェックとリンター実行

こういうのを全部バックグラウンドでやってくれる。

さらに、AI エージェントがドキュメントを更新したり、ボイラープレートコードを書いたりしてくれるから、ワイは本質的なビジネスロジックだけに集中できる。

これって理想的な開発体験やと思わへん？


プロトタイプから本番環境まで一貫した体験

Kiro のキャッチフレーズが「prototype to production」なんよね。これがどういう意味か考えてみると、めっちゃ深いんよ。

普通、プロトタイプって「とりあえず動くもの」を雑に作る段階やん。で、それを本番に持っていくときに、コードをクリーンアップして、テスト書いて、ドキュメント整えて…ってめっちゃ手間がかかるんよ。

最悪の場合、プロトタイプを全部捨てて書き直しとかもある。これってめっちゃ無駄やんな。

Kiro は最初からスペック駆動で進めるから、プロトタイプの段階でもちゃんと設計されてて、テストもドキュメントもある。だから本番に持っていくときのギャップがめっちゃ小さいんよ。

これは特にスタートアップとか、スピード重視の開発環境で威力を発揮すると思う。「とりあえず動くもの」と「本番レベルのコード」の間で悩まなくていいんや。


懸念点はないん？

めっちゃ良さそうな Kiro やけど、懸念点もあるんよね。

まず、学習コスト。スペック駆動開発に慣れてない人にとっては、最初は戸惑うかもしれん。「とりあえずコード書きたいんやけど」ってなる人もおるやろな。

次に、AI への依存度。エージェントが勝手に色々やってくれるのは便利やけど、その分「何が起きてるか分からん」状態になりやすい。特に初学者は、AI が生成したコードを理解せずに使っちゃう危険性がある。

あと、コストも気になるところ。Pro プランで月 1,000 インタラクションって、めっちゃ開発してたらすぐ使い切りそうやん。大規模プロジェクトだと Pro+ でも足りなくなるかもしれへん。

最後に、プライバシーとセキュリティ。コードを AI に送信するわけやから、機密性の高いプロジェクトでは使いにくいかもしれん。オンプレミス版とかエンタープライズ向けのプランが出てくるかどうかが気になるところや。


まとめ

Amazon が放った Kiro は、単なる AI コーディングアシスタントやなくて、開発フロー全体を変革しようとするツールや。スペック駆動開発、自律的な AI エージェント、イベント駆動の Hooks、これら全部が組み合わさって、プロトタイプから本番環境まで一貫した開発体験を提供してくれる。

GitHub Copilot や Cursor みたいなツールが「コードを書く」ことを助けてくれるのに対して、Kiro は「何を作るべきか」から「どう作るか」「どうテストするか」「どうドキュメント化するか」まで全部面倒見てくれるんよね。

現在はプレビュー期間で無料やから、興味ある人は今のうちに触っておくのがおすすめや。将来的には月額 19 ドルからの有料プランになる予定やけど、提供される価値を考えるとめっちゃコスパいいと思う。

ワイも早速試してみようと思ってるんやけど、これがうまくいったら開発の仕方が本当に変わるかもしれんな。2025 年は AI エージェントが開発現場に本格的に入ってくる年になりそうや
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[git worktree の仕組みとブランチとの使い分け]]></title>
            <link>http://izanami.dev/post/f077e2a4-e372-47cf-aac3-8d3264b3f9e2</link>
            <guid>http://izanami.dev/post/f077e2a4-e372-47cf-aac3-8d3264b3f9e2</guid><dc:creator>Nexyl</dc:creator>
            <pubDate>Sun, 09 Nov 2025 09:21:49 GMT</pubDate>
            <description><![CDATA[worktreeとは、1つのリポジトリ内に、異なるブランチの作業場所（ワーキングツリー）を複数作成する仕組みです。

これにより、あるブランチで作業している状態を維持したまま、別のブランチの作業を同時]]></description>
            <content:encoded><![CDATA[worktreeとは、1つのリポジトリ内に、異なるブランチの作業場所（ワーキングツリー）を複数作成する仕組みです。

これにより、あるブランチで作業している状態を維持したまま、別のブランチの作業を同時に、かつ物理的に異なるディレクトリで進められるようになります。

- ブランチ (Branch)は、「履歴の枝分かれ（何の作業か）」を記録するもの
- Worktree (ワーキングツリー)は、「作業を行う場所（どのフォルダか）」を提供するもの


「ブランチ」と「worktree」の使い分け

「ブランチ」と「worktree」の使い分けは、「何をしたいか」によって明確に分かれます。基本的な考え方は、以下の通りです。

| 機能 | 目的 | いつ使うか |
| :--- | :--- | :--- |
| ブランチ | 開発の履歴を分ける（作業の論理的な区切り） | 新しい機能を作るとき、バグを修正するときなど、変更を隔離して残したいとき |
| Worktree | 作業環境を分ける（作業の物理的な場所） | 複数の作業を同時に進めたいときや、ブランチを切り替えずに別の作業をしたいとき |


ブランチを使うとき

ブランチは、Gitの中心的な機能であり、「この変更は一連の作業として記録しておこう」という、論理的な区切りを作るために使います。

1. 新しい機能の開発や修正を始めるとき

 新しい機能（フィーチャー）開発を始める際 ()。
 本番環境のバグを修正する際 ()。
 既存のブランチから派生して、別のアイデアを試す際。

2. 作業を記録し、レビュー・統合するとき

 作業を小さな単位でコミットとして履歴に記録するとき。
 他のメンバーにレビューを依頼するとき（プルリクエスト/マージリクエスト）。
 作業が完了し、 ブランチなどの主軸の履歴に統合するとき。

→ 「変更履歴を管理・分離したい」のがブランチの役割です。


worktree を使うとき

worktreeは、今やっている作業を中断したくないが、別のブランチでの作業をすぐに開始したいという、環境的なニーズがあるときに使います。

1. 緊急のバグ修正（ホットフィックス）

  ブランチで作業中、緊急で  のバグを直す必要が生じた。
 → 今の作業をコミットしたりスタッシュしたりせずに、 で別のフォルダに  ブランチをチェックアウトし、すぐに修正に取り掛かる。

2. 複数の並行作業

 機能A () の開発が一段落したが、レビュー待ち。その間に、機能B () の開発に着手したい。
 → フォルダAで  を開き、フォルダBで  を開く。フォルダを切り替えるだけで、それぞれの作業を独立して進められる。

3. レビューやテストの実施

 同僚からレビュー依頼が来たプルリクエストのブランチを、ローカルでビルドして動作確認したい。
 → 今の作業フォルダを汚さずに、レビュー専用の worktree を作り、そのブランチをチェックアウトして確認する。

→ 「作業環境を分離・並行化したい」のがworktreeの役割です。


まとめ：使い分けの判断基準

| 質問 | 使う機能 |
| :--- | :--- |
| 「この変更を履歴として隔離したい？」 | ブランチ () |
| 「今の作業を中断せずに別のブランチで作業したい？」 | Worktree () |

多くの日常的な開発作業では「ブランチ」が使われますが、並行作業や緊急対応の効率を上げるために「worktree」が非常に役立ちます。


worktree で作られるディレクトリは 「仮想」ではなく、実際に存在する物理フォルダ です。
そして、Gitの内部構造を壊さないために、プロジェクトの直下ではなく、外側（兄弟ディレクトリ）に作成するのが一般的です。

具体的にどうなるか

例えば、今  という Git リポジトリがあるとします。



ここで次のコマンドを打つと:



すると、 と同じ階層に新しいフォルダが作られます。



つまり

  フォルダは実際にディスク上に作られる
 実体はコピーではなく、 や  だけ個別に持っている
  は本体を共有するのでリポジトリが増えるわけではない

なぜプロジェクト内に作らないのか？

理由は 「Git が内部的に誤認するのを防ぐため」 です。

  配下に作ると Git が「不要なファイル」として掃除（prune）してしまうことがある
 ツールや IDE が  内にあるコードを誤認識して予期せぬ動作をすることがある
 Git 公式も 兄弟ディレクトリに作る方法を推奨しています

そのため、以下のような構成が推奨されます。




プロジェクト内に置く方法（非推奨）

技術的には、以下のようにプロジェクト内に作ることも可能です。



しかし、前述の通り、Gitが意図せず削除するリスクがあるため、この方法は推奨されません。


worktreeはファイルのコピーではない

| 質問 | 答え |
| :--- | :--- |
| worktree は仮想ディレクトリ？ | いいえ、物理フォルダとして作られます |
| そのフォルダはプロジェクト内？ | 作成は可能ですが、非推奨です |
| 一般的にはどこに作る？ | プロジェクトの兄弟フォルダ（）です |

worktree は「プロジェクト全体を丸ごとコピーしているわけではありません」。
見た目はコピーされたフォルダに見えますが、実際には Git の内部データを共有し、最低限の差分だけを持つ仕組みになっています。

実際にどうなっているのか？

例として、次のコマンドを実行するとします。



すると  というフォルダができますが、これは

 ファイルは「その時点のブランチの内容」が展開される
 履歴（コミットログなど）は  本体を共有
  は本物ではなく「リンク情報」だけを持つ小さなファイル

コピーではない証拠

作られた worktree 内の  ファイルの中身を確認すると、参照先が書かれていることがわかります。



つまり

 通常の Git リポジトリではない
  本体は 親プロジェクトと共有されている
 履歴が二重管理されるわけではない（ディスク容量をほぼ増やさない）

何が共有され、何が独立するのか？

worktree ごとに持つデータは「作業中の状態だけ」です。

| 状態 | 内容 |
| :--- | :--- |
| 共有される | Git 履歴（コミット、ブランチ、タグなど） |
| 共有される | オブジェクトデータ () |
| 独立する | チェックアウトされているファイルの状態 |
| 独立する | HEAD（どのブランチを見ているか） |
| 独立する | index（ステージング状態） |

わかりやすく例えると

 通常のブランチ切り替え: 1つの作業机の上で、参照する設計図を次々に入れ替えるようなもの。
 worktree: 設計図（リポジトリ）は共有しつつ、作業机（ディレクトリ）を複数用意するようなもの。机ごとに異なる道具やメモ（作業ファイルやステージング状態）を広げられる。

巨大なプロジェクトでも軽量な理由

巨大なリポジトリ（例: 5GB）でも worktree フォルダを作るときに、5GB がまるごとコピーされるわけではありません。
共有の仕組みにより、実際に増えるディスク容量は数 MB〜数百 MB 程度です。

結論

| 質問 | 答え |
| :--- | :--- |
| プロジェクトを丸ごとコピーしている？ | いいえ、していません |
| では何を共有している？ | Git 履歴・オブジェクト・メタデータです |
| worktree ごとに独立しているものは？ | 作業ファイル・HEAD・index です |
| ディスク容量はどうなる？ | 最小限だけ増えます（実質差分のみ） |

]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Codex CLI アシスタント利用ガイド]]></title>
            <link>http://izanami.dev/post/be8ad2f2-240a-4f4d-b713-d105ecb44eba</link>
            <guid>http://izanami.dev/post/be8ad2f2-240a-4f4d-b713-d105ecb44eba</guid><dc:creator>Nexyl</dc:creator>
            <pubDate>Mon, 27 Oct 2025 16:40:14 GMT</pubDate>
            <description><![CDATA[Codex CLI の使い方がよく分からないので、本人（Codex CLI）にドキュメントを作ってもらいました。

このドキュメントは、Codex CLI 上で動作するアシスタントが何をできるか、どう]]></description>
            <content:encoded><![CDATA[Codex CLI の使い方がよく分からないので、本人（Codex CLI）にドキュメントを作ってもらいました。

このドキュメントは、Codex CLI 上で動作するアシスタントが何をできるか、どう依頼すれば良いか、作業方針や制約をまとめたものです。このガイドに沿って依頼いただければ、短い往復で安全かつ的確に成果物をお返しできます。必要に応じて本ドキュメントも更新します。

概要

- 役割: 既存リポジトリでの実装・修正・解析・ドキュメント化を、最小の変更で安全に進めます。
- 対象: アプリ/ライブラリ実装、バグ修正、リファクタ、テスト/CI、スクリプト、設定、ドキュメント作成。
- スタイル: 簡潔・直接的・実務的。必要なところだけ説明し、即実行します。

主な能力

- リポジトリ理解/探索
  - 高速全文検索（）でコードや設定を横断的に把握
  - 依存関係・ファイル構造・実装箇所の特定、影響範囲の見立て
- 実装/変更
  - 機能追加、バグ修正、軽量リファクタ、設定やスクリプトの整備
  - ドキュメント執筆・更新（README、設計メモ、CHANGELOG など）
  - 既存コードスタイルを尊重した最小差分のパッチ作成（）
- 解析/レビュー
  - 設計・アーキテクチャの要点整理、改善提案
  - パフォーマンス/可読性/保守性の観点からの指摘
  - セキュリティ上の明らかなリスクや脆弱なパターンの指摘
- テスト/ビルド
  - 既存テストやビルドの実行（環境が許す範囲で）
  - 変更箇所に即した最小限のテスト追加（テスト文化がある場合）
  - 既存のフォーマッタ/リンタの起動（設定がある場合）
- 自動化/運用周り
  - Makefile / npm scripts / CI 設定の追加・調整
  - 小規模なスクリプト（CLI/補助ツール）の作成
- ドキュメント/コミュニケーション
  - 概要・手順書・運用ガイド・API 仕様のたたき台作成
  - 進捗の短い共有、次アクションの提案

制約と前提

- サンドボックス: 今回の実行は「読み取り専用」。ファイル変更は承認が必要です。
- ネットワーク: 制限あり。新規パッケージの取得や外部 API へのアクセスは承認が必要です。
- 承認フロー: 書き込み・ネットワーク・破壊的操作（例: ）は事前に意図を共有し、承認を依頼します。
- 方針:
  - 最小変更・目的直結・既存スタイル遵守
  - 無関係な不具合は修正しません（必要なら別途提案）
  - ライセンス/著作権ヘッダは追加しません（明示依頼時のみ）
- 非対応/注意
  - GUI 操作や長時間の外部環境構築は不可/不向き
  - 外部秘密情報（トークン/鍵）は扱いません

作業の進め方（プロセス）

1. 依頼の確認と意図合わせ
2. 必要に応じて簡潔な計画（）を提示・更新
3. 実行前に 1–2 行のプレアンブルで直近アクションを共有
4. 変更は  でパッチ化（最小差分）
5. 実行/検証（テストやビルドがあれば活用）
6. 進捗と結果を端的に共有、次アクションを提案

よく使う操作例

- コード検索:  / ファイル一覧: 
- ファイル閲覧: （長文は分割）
- パッチ適用:  による追加/更新/削除
- テスト/ビルド: 既存スクリプトやツールを優先的に使用

依頼の書き方（おすすめ）

- 目的/背景: 何のための変更か（なぜ今か）
- 期待アウトカム: 完了の判定基準（動作/ドキュメント/差分/デモなど）
- 対象範囲: 触ってよい範囲/触らない範囲、関連ファイル
- 制約/優先度: 期限、パフォーマンス/互換性要件、依存の可否
- 実行環境: 実行/テスト方法、利用可能なコマンド
- 参考情報: Issue、仕様、関連 PR/コミット、ログ/スクショ

出力・コミュニケーションスタイル

- 見出しと箇条書き中心で簡潔に共有
- コマンド/パス/識別子はバッククォートで明示
- 変更内容はファイルパス単位で要点共有（全量貼り付けは最小限）

既知の現在環境（このセッション）

- 作業ディレクトリ: 
- 承認ポリシー: on-request（必要時に書き込み/ネットの承認を依頼）
- サンドボックス: read-only（書き込みは承認後に実施）
- ネットワーク: restricted（外部アクセスは原則不可）

使い始めのチェックリスト

- 目的/完了条件は明確か
- 触ってよい範囲は定義されているか
- 実行/検証手順は共有されているか
- 必要な承認（書き込み/ネット）はあるか
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Opus 4 / Sonnet 4 の衝撃と可能性]]></title>
            <link>http://izanami.dev/post/9c4bbf8b-4fe3-4d87-b491-069a8a5e38c2</link>
            <guid>http://izanami.dev/post/9c4bbf8b-4fe3-4d87-b491-069a8a5e38c2</guid><dc:creator>Nexyl</dc:creator>
            <pubDate>Thu, 19 Jun 2025 09:52:30 GMT</pubDate>
            <description><![CDATA[結論：Claude 4 は「開発の相棒」として完成に近づいた

個人的には、Claude Opus 4 を使い始めて「あ、もうこれでいいな」ってなった。以前までは GPT-4 との併用が前提だったけど]]></description>
            <content:encoded><![CDATA[結論：Claude 4 は「開発の相棒」として完成に近づいた

個人的には、Claude Opus 4 を使い始めて「あ、もうこれでいいな」ってなった。以前までは GPT-4 との併用が前提だったけど、今回の Opus 4 / Sonnet 4 のリリースで、そのバランスが一気にClaude側に傾いた感じ。

特に「コーディング」や「長時間作業」に関しては、Claudeが完全に覇権を取りにきた印象。

実際、公式発表でも「SWE-bench（ソフトウェア工学ベンチマーク）」や「Terminal-bench」で世界最高スコアを叩き出してるし、Replit や Cursor など、現場で使ってる企業・プロダクトが口を揃えて「まじで一段階上」って言ってる。

Claude 4ってそもそも何？

Claude 4 は、Anthropic 社が開発した大規模言語モデル（LLM）の最新世代で、「Claude Opus 4」と「Claude Sonnet 4」の2モデルが存在する。

特徴的なのは、以下のような点

 人間との“対話”だけでなく“継続的な思考”にフォーカスして設計されている
 ローカルファイルやツールへのアクセスも可能（開発者による設定）
 コーディングタスクへの最適化が強く、従来の LLM を大きく超える精度と一貫性
 『思考要約』や『記憶』といったメタ認知的な機能も搭載

名前の由来は「クロード・シャノン」から来ていると思われる。GPTと違い、より倫理重視、安全性重視の設計思想が強く、Anthropic社の哲学も反映されてる印象。

Claude 4は「バイブコーディング」との相性どう？

これ、めちゃくちゃ良い。
なぜなら、バイブコーディング（= なんとなくコードを書く、ノリで触って探る、体で覚える開発スタイル）って、以下のような場面が多い

 とりあえず思いついたコードをガッと書く
 意図がうまく言語化できないが「雰囲気」はある
 書きながら「あれ、これなんだっけ？」と止まる
 急に構造を変えたくなる

この時、Claudeは

 過去のやりとりを自然に覚えていてくれる（メモリ機能）
 意図が曖昧なままでも、文脈から補完してくれる（Steerability）
 思いついたことをすぐコードにしてくれる（Claude Code）

ので、「何となく→コードになる」のサイクルがめちゃくちゃ早い。

特にOpus 4の長時間集中力はすごくて、普通のモデルが「え？前何やってたっけ？」となるようなセッションでも、Claudeは淡々と脳内に残ってる“ノリ”を維持してくれる。

バイブコーディングとは、ある意味「流れを止めないこと」なので、そういう意味ではClaude 4は最適解に近い。特に“ながら開発”や“リズム優先”派にはドンピシャ。

Claude 4 はここがすごい（ポイントまとめ）

| 項目          | 内容                                                    |
| ----------- | ----------------------------------------------------- |
| モデル名        | Claude Opus 4 / Sonnet 4                              |
| コーディング性能    | SWE-bench 72.5%（Opus 4）・72.7%（Sonnet 4）で最高スコア         |
| ターミナル操作性能   | Terminal-bench 43.2%（Opus 4）                          |
| 長時間処理       | 7時間連続でOSSリファクタを完走（Rakuten事例）                          |
| メモリ（記憶）機能   | ローカルファイルから知識を継続的に保持し、思考を維持                            |
| Claude Code | GitHub Actions / VS Code / JetBrains 対応、CLI からペアプロも可能 |
| 思考の要約       | 考えすぎたら自動で要約（ただし発生は5%程度）                               |
| API 拡張機能    | Code実行・MCP接続・ファイル操作・プロンプトキャッシュなどが可能に                  |

Claude 4の思考は“続いている”

Claude 4では、ユーザーがファイルを渡すことで、Claude側が「重要情報を抜き出し・メモ化」してくれるようになった。つまり、その場限りの応答ではなく「継続的な文脈理解」ができるようになった。

例：Claudeがポケモンのプレイ中に“Navigation Guide”を自作しながら行動していた話。

このように、Claude 4は一時的な推論だけでなく、次回のタスクや連続作業に備えて“記憶”を残すことができる。

Developer Mode で“思考ログ”を全部取る

Claude 4では一部の長すぎる思考過程は、自動的に要約される。でも、開発者モード（Developer Mode）を有効にすれば、Claudeの全思考ログを取得できる。

これにより

 Claudeがどう判断したかの全プロセスが見える
 自分の提示したプロンプトがどう解釈されていたかがわかる
 “LLMO”（LLM Optimization）に使える学習素材になる

Claude 4 + LLMO 対策

Claudeは、以下のような構成でLLMO対策に役立てられる：

1. Claudeを開発パートナーとして使う（コード生成やレビュー）
2. Claudeが保持した“記憶”でコンテキストをつなげる
3. 思考ログをDeveloper Modeで収集
4. 自分の思考パターンをClaudeに学習させて、補完精度を上げる
5. 定期的に過去のやりとりをClaudeが要約して「進捗報告」や「改善提案」をくれるようにする

つまり、“AIとの会話が知的資産”になる設計ができる。

Claude 4 をベースにしたエージェント構築の可能性

Claude Code SDKも登場した今、「Claudeを軸にした独自エージェント」を作るのが現実的になってきた。

 Claudeの推論+記憶+要約をベースに、LLMワークフローを構築
 特定のプロジェクトやドメインに特化したClaudeラッパーを作る
 GitHub ActionsやCIフローに組み込むことで、Claudeが自律的に“エラーを見つけて修正”も可能

今までの“人間が指示 → LLMが返す”というスタイルから、“Claudeが継続的に作業に関わる”スタイルへの進化が始まっている。

終わりに

Claude 4は「コーディングAI」の枠を超え、“思考パートナー”になってきている。しかもそれは、ただ便利なツールというより、“学び続ける相棒”に近い存在。

これからの開発は、「AIが手伝う」ではなく「AIと一緒に考える」時代。Claude 4を使ったエージェント開発やLLMO最適化は、その最初の一歩になると思う。

参考：[https://www.anthropic.com/news/claude-4](https://www.anthropic.com/news/claude-4)

]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[なぜ個人開発でも GitHub Flow が必要なのか？]]></title>
            <link>http://izanami.dev/post/e30ec22d-f38f-425f-a1ad-75d44789cc87</link>
            <guid>http://izanami.dev/post/e30ec22d-f38f-425f-a1ad-75d44789cc87</guid><dc:creator>Nexyl</dc:creator>
            <pubDate>Sun, 15 Jun 2025 18:28:21 GMT</pubDate>
            <description><![CDATA[個人開発者の君、mainにだけpushしてない？

結論：GitHub Flowは一人開発者の命綱

mainに直接pushしてると、うっかりバグを本番に出したり、後から何をやったか思い出せなかったり]]></description>
            <content:encoded><![CDATA[個人開発者の君、mainにだけpushしてない？

結論：GitHub Flowは一人開発者の命綱

mainに直接pushしてると、うっかりバグを本番に出したり、後から何をやったか思い出せなかったり、サービスが成長したときに人を巻き込めなくなったりする。つまり、GitHub Flowを取り入れることで、そういった「やらかし」を未然に防げる。

特にVercelやCloudflare Workersのような「GitHubにpushするだけで本番デプロイされる」環境では、GitHub Flowが実質的な安全装置になる。この記事では、一人開発者でもGitHub Flowを導入すべき理由をまとめておく。

GitHub Flowって何？

まずは基本の確認から。

GitHub Flowとは、GitHubでのシンプルかつ安全な開発フローのこと。手順はこんな感じ。

| ステップ             | 内容 |
|---------------------|------|
| mainは常に安定状態 | いつでも本番反映できる状態を維持 |
| 変更はブランチで作業 | 直接mainに触らず、別ブランチで作業 |
| 開発後にPRを作成     | Pull Requestを出して変更を確認 |
| レビューしてマージ   | 問題なければmainにマージ |
| 自動で本番に反映     | CI/CDでデプロイされる |

要するに「mainにマージされたものだけがデプロイされるようにする仕組み」ってことやな。

「自動デプロイできるならPRいらなくない？」は罠

VercelやCloudflare Workersを使っていると、pushしただけで即デプロイされるから、わざわざPRを切らなくてもいい気がしてくる。だけどそれ、かなり危ない。

mainにpushするだけで済ませてると、以下のようなことが起きる。

理由1：本番が壊れる事故を防げる

mainにpushしたコードがそのまま本番に出るってことは、バグや作業途中の変更がダイレクトにユーザーに届くってこと。怖くない？

PRを通すようにすれば、一度立ち止まって確認できる。しかもVercelには、ブランチごとにpreview環境が勝手にできる機能がある。

| ツール | プレビューURL例 |
|--------|----------------|
| Vercel |  |
| Workers | （設定による） |

このプレビューで表示崩れやバグを確認してからマージすれば、「気づかず本番に出してしまった…」がほぼゼロになる。

理由2：変更の文脈が履歴に残る

PRには「なぜその変更をしたのか」「何を修正したのか」という背景が書ける。コミットログだけじゃ分からない理由もPRコメントで残せる。

たとえば後日こう思うはず。

- 「この関数の名前、なんで変えたんだっけ？」
- 「あれ？ここのロジック、前にバグあったっけ？」

PRを使っておけば、こうした疑問に自分の書いた説明で答えられるようになる。

理由3：チーム化しやすくなる

最初は一人でも、サービスが伸びてきたら外注やコントリビューターを迎えるかもしれない。そのときにGitHub Flowで運用していれば、すぐに共同作業に切り替えられる。

逆にmain直pushが常態化してると、他人が入りづらくて「属人化地獄」に陥る。

理由4：PRごとのプレビュー機能が活きる

GitHub Flowを前提に、VercelやWorkersのpreview機能が活用できる。PRを出すと自動的に確認環境ができるから、動作チェックやUIテストがやりやすい。

これを使わない手はない。

main直pushだと、本番しか確認できない。つまり、PRプレビューがないと、UI崩れも気づきにくくなる。

理由5：作業が小さく、トラブルに強くなる

PRをベースに作業するようになると、自然と「1PR = 1機能」みたいに細かく分けるようになる。これ、実はめっちゃ大事。

- レビューしやすい
- デグレしにくい
- バグの切り分けが簡単
- コードが読みやすい

逆にmainに大きな変更をまとめてpushしてると、どこでバグったか分からず地獄を見ることになる。

どうやってGitHub Flowを始めるか？

実はすごく簡単。

| やること | 詳細 |
|----------|------|
| mainは触らない | 基本、直接編集しない |
| ブランチを切る | 例：や |
| PRを作る | GitHub上でクリックだけでOK |
| CI/CDと連携 | Vercelなら勝手にやってくれる |

この4ステップで、あなたもGitHub Flow運用ができるようになる。

GitHub Flowを使わないとどうなるか？（実例）

- mainにpushしたら、ページが真っ白に…
- 数日前の変更を戻したいけど、どれを直したか分からない
- UI修正したけど、スマホ表示崩れてたまま本番反映
- 他人にコードの意図を聞かれて説明できず赤面

こういうの、全部GitHub Flowで避けられた話なんよね。

まとめ：GitHub Flowは「安心開発の最小単位」

GitHub Flowって、一見すると「チーム開発のためのフロー」に見えるけど、実は「一人開発でも事故を防げる、思考の整理ができる、スケーラブルになる」仕組み。

特にVercelやWorkersみたいなCI/CD前提の環境では、GitHub Flowと組み合わせることで、まさに最強の開発体験になる。

もし今、mainに直でpushしてるなら、今日からでもPRベースの開発に切り替えてみてほしい。GitHub Flowは、未来の自分へのやさしさそのもの。

終わりに

GitHub Flowはチーム開発者だけのものじゃない。むしろ、うっかりミスや「後で困る」を防ぎたい一人開発者にこそ向いている。

mainにpushして爆発する前に、今日からブランチ切って、PR出して、プレビュー見てからマージしてみよう。それだけで、個人開発の質がグッと上がるから。
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[LLMO対策完全ガイド - AI時代のコンテンツ最適化]]></title>
            <link>http://izanami.dev/post/d6d6cbc3-65ea-4c68-9fd1-e84f4cee998c</link>
            <guid>http://izanami.dev/post/d6d6cbc3-65ea-4c68-9fd1-e84f4cee998c</guid><dc:creator>Nexyl</dc:creator>
            <pubDate>Thu, 12 Jun 2025 16:59:11 GMT</pubDate>
            <description><![CDATA[LLMO対策は、LLMが回答する際にサイトを引用されやすくする施策ですが、SEO がなくなるわけではないので、SEOを無視してよいわけではないです。

LLMO も SEO もまだまだ大切な施策です。]]></description>
            <content:encoded><![CDATA[LLMO対策は、LLMが回答する際にサイトを引用されやすくする施策ですが、SEO がなくなるわけではないので、SEOを無視してよいわけではないです。

LLMO も SEO もまだまだ大切な施策です。それでは一体どのように書くべきかというと、この記事のように構造化すると AI が理解しやすいんですね。

まずは、従来のSEOとどう違うのか？というところから解説します。

従来のSEOとの違い

| 項目           | 従来のSEO                        | LLMO（大規模言語モデル最適化）                 |
| ------------ | ----------------------------- | --------------------------------- |
| ターゲット        | 検索エンジン（Googleなど）              | AIアシスタント・チャットボット（ChatGPTなど）       |
| 目的           | 上位表示されて検索流入を得る                | 回答候補に選ばれ、AI経由での流入や紹介を得る           |
| 重視される要素      | キーワード、被リンク、メタタグ、サイト構造         | 構造化データ（JSON-LD）、文脈、自然言語のわかりやすさ    |
| キーワード最適化     | 明示的なキーワードの挿入が重要               | 質問文との意味的整合性（意図をくみ取れる表現）が重要        |
| 被リンク（バックリンク） | 強力な評価指標                       | ほとんど影響しない（ただしWeb上での認知は有利）         |
| インデックス化      | Google bot によるクローリング＆インデックス化  | LLM の事前学習、もしくはRAGで参照されるかどうか       |
| 技術的施策        | サイトマップ、robots.txt、CSP、ページ速度など | JSON-LD構造化、FAQ/Q\&A形式、ナレッジベース統合など |
| コンテンツ形式      | 見出し・本文の明確な構造が推奨               | 自然な文章・対話形式・明確な問いと答えがある形式が効果的      |
| 成果の出方        | 数週間〜数ヶ月かかる                    | RAG/LLMが参照する場合、即日で結果に反映される可能性もある  |
| 主な想定ユースケース   | Google/Yahoo経由の流入             | AIアシスタントによる推薦、検索代替、RAG回答          |
| メタ情報の扱い      | description/title/metaタグが重要   | JSON-LD による構造化スキーマが重要             |


従来のSEOが検索エンジンのアルゴリズムを対象とした最適化であるのに対し、LLMOはAIによる情報抽出・引用を意識した新しい最適化戦略です。具体的には以下の点で異なります。

- 対象の違い: SEOは検索エンジン、LLMOはAIモデル
- 評価基準の違い: SEOはページランクや被リンク、LLMOは情報の構造化と信頼性
- ユーザー体験の違い: SEOはクリック誘導、LLMOは直接的な情報提供

なぜLLMO対策が重要なのか？

2024年以降、AI検索エンジンの普及により「ゼロクリック検索」が急増しています。ユーザーが検索結果ページではなく、AI生成の回答で情報を得る傾向が強まっているため、AIに「選ばれる情報源」となることが企業のオンライン戦略において極めて重要になっています。

LLMO対策の詳細なポイント

1. 構造化データの実装

推奨される構造化データの種類

FAQPage


Article


HowTo


構造化データ実装のメリット

- AIがコンテンツの文脈と意味を正確に理解
- Q&amp;A形式での情報抽出が容易
- 手順型情報の構造化による引用率向上
- 著者情報や公開日の明確化

2. 信頼性・権威性（E-E-A-T）の強化

Experience（経験）の示し方

- 実体験の記述: 実際に使用した製品やサービスの体験談
- 画像・動画の活用: 実際の使用風景や検証過程の記録
- 時系列の明記: いつ、どのような条件で経験したかの詳細

Expertise（専門性）の向上

- 専門的な見解の提供: 業界の深い知識に基づく分析
- 技術的な詳細説明: 一般的でない専門用語の適切な使用
- 関連資格や経歴の明記: 著者の専門性を証明する情報

Authoritativeness（権威性）の構築

- 被リンクの獲得: 権威あるサイトからの自然なリンク
- メディア露出: 新聞、雑誌、テレビでの引用や言及
- 業界での認知: 専門分野での講演や寄稿実績

Trustworthiness（信頼性）の確保

- 一次情報の活用: 独自調査、統計データ、公式発表
- 出典の明記: 引用元の詳細な記載
- 定期的な情報更新: 最新情報への継続的なアップデート
- 透明性の確保: 利害関係や偏見の開示

3. HTML構造とページ設計の最適化

論理的な見出し構造



AIが理解しやすいHTML要素

- メインコンテンツの明確化
- 記事コンテンツの識別
- セクションの論理的な分割
- 補足情報の分類
- 日付・時刻の構造化

パフォーマンス最適化

- ページ読み込み速度: 3秒以内の表示
- Core Web Vitals: LCP、FID、CLSの改善
- モバイルファースト: レスポンシブデザインの徹底
- 画像最適化: WebP形式の活用、遅延読み込み

4. 明確で簡潔な文章構成

結論ファーストの文章構造

1. 結論・要点の提示（冒頭100文字以内）
2. 根拠・詳細説明（論理的な展開）
3. 具体例・事例（理解を深める情報）
4. まとめ・行動喚起（次のステップの提示）

視覚的な情報整理

- 箇条書きの活用: 複数の要素を並列で示す
- 表・グラフの使用: 数値データの視覚化
- 強調表示: 重要なポイントの太字やマーカー
- 段落の分割: 一つの段落は3-4文以内

引用と出典の適切な記載



5. llms.txtの設置と管理

llms.txtの基本構文



設置場所と管理方法

- 設置場所: サイトルート（example.com/llms.txt）
- 更新頻度: 月1回の見直し
- 検証方法: AI学習データでの自社コンテンツ出現確認

6. ブランディング・PR戦略の統合

外部メディア戦略

- プレスリリース配信: 権威あるメディアへの情報提供
- 専門家としての寄稿: 業界誌やオンラインメディアでの記事執筆
- ポッドキャスト・ウェビナー: 音声・動画コンテンツでの発信

ソーシャルメディア連携

- LinkedIn: B2B向け専門情報の発信
- X（Twitter）: リアルタイム情報の共有
- YouTube: 詳細な解説動画の制作
- Instagram: ビジュアル中心の情報発信

レビュー・評判管理

- Googleビジネスプロフィール: 地域SEOとの連携
- 業界レビューサイト: 専門分野での評価向上
- お客様の声: 実際の利用者からのフィードバック収集

LLMO対策の詳細な実践ステップ

Phase 1: 現状分析（1-2週間）

コンテンツ監査

1. 既存コンテンツの棚卸し
   - 記事数、文字数、更新頻度の確認
   - 見出し構造の分析
   - 画像・動画コンテンツの評価

2. 構造化データの現状確認
   - Google構造化データテストツールでの検証
   - Schema.orgマークアップの有無確認
   - エラー・警告の洗い出し

3. 競合分析
   - 同業他社のLLMO対応状況
   - AI検索での競合コンテンツ出現率
   - 差別化ポイントの特定

技術的な現状把握

- ページ表示速度: PageSpeed Insightsでの測定
- モバイル対応: Mobile-Friendly Testでの確認
- アクセシビリティ: WAVE等のツールでの検証

Phase 2: 基盤整備（2-4週間）

構造化データの実装

1. 優先順位の決定
   - FAQPage: Q&amp;Aコンテンツから開始
   - Article: 主要記事への適用
   - Organization: 企業情報の構造化

2. 段階的な実装
   - 週10-20ページずつの実装
   - Google Search Consoleでの検証
   - エラー修正とブラッシュアップ

HTML最適化

- 見出し構造の見直し: 論理的な階層の構築
- メタデータの最適化: title、description、ogタグ
- 内部リンク構造の改善: 関連記事との適切な結び付け

Phase 3: コンテンツ最適化（4-8週間）

既存コンテンツの改善

1. 高優先度記事の特定
   - アクセス数上位の記事
   - 検索順位上位の記事
   - 専門性の高い記事

2. E-E-A-T強化施策
   - 著者情報の詳細化
   - 一次情報・独自データの追加
   - 最新情報への更新

新規コンテンツ制作

- AI検索を意識したトピック選定
- FAQ形式での情報提供
- ステップバイステップの手順解説

Phase 4: 外部対策（継続的）

権威性向上施策

- 業界メディアへの寄稿
- 専門イベントでの講演
- 他社との共同研究・調査

ソーシャルシグナルの強化

- 定期的な情報発信
- 業界内でのネットワーキング
- ユーザーとのエンゲージメント向上

効果測定と改善

主要KPIの設定

直接指標

- AI検索での言及回数: ChatGPT、Claude等での自社情報出現率
- 引用元としての選択率: AIが参照する情報源としての割合
- ブランド認知度: AI回答での自社名言及頻度

間接指標

- オーガニック検索流入: Google等従来検索からの流入
- 直接流入: ブランド検索やURL直接入力
- 滞在時間・エンゲージメント: ユーザーの行動指標

測定ツールの活用

専用ツール

- TACT SEO: LLMO対策専用の分析機能
- Ahrefs: 被リンク・競合分析
- SEMrush: キーワード・コンテンツ分析

無料ツール

- Google Search Console: 検索パフォーマンスの確認
- Google Analytics: ユーザー行動の分析
- PageSpeed Insights: ページ表示速度の測定

継続的な改善プロセス

月次レビュー

1. KPI達成状況の確認
2. 新たな課題の特定
3. 競合動向の分析
4. 改善施策の立案

四半期見直し

- 戦略の再評価
- 新技術・トレンドへの対応
- リソース配分の最適化

業界別LLMO対策のポイント

YMYL分野（医療・法律・金融）

- 専門家監修の明記: 医師、弁護士、公認会計士等の監修
- 公的機関データの活用: 厚生労働省、金融庁等の一次情報
- 免責事項の適切な記載: リスクや制限事項の明確化

ECサイト

- 商品レビューの構造化: 星評価、コメントの構造化データ
- 在庫・価格情報の最新化: リアルタイム更新の仕組み
- 配送・返品情報の明記: 購入判断に必要な詳細情報

B2Bサービス

- 事例・導入実績の詳細化: 具体的な成果数値の記載
- 比較表・機能一覧: 競合との差別化ポイント
- 技術仕様書: エンジニア向けの詳細情報

今後の展望とトレンド

AIの進化とLLMO対策

- マルチモーダルAI: 画像・動画も含めた最適化
- リアルタイム学習: 最新情報への即座の対応
- パーソナライゼーション: ユーザー個別の情報提供

新たな技術動向

- 音声検索の普及: 話し言葉に対応したコンテンツ
- AR/VR検索: 没入型体験での情報提供
- IoTデバイス連携: スマートスピーカー等への最適化

まとめ

LLMO対策は、今後の「ゼロクリック時代」やAI検索時代において、AIに「選ばれる情報源」となるための必須施策です。従来のSEOの延長線上にありつつも、AI特有の情報抽出ロジックを意識した以下の要素が重要となります。

1. 構造化された情報提供: Schema.orgマークアップとHTML最適化
2. 信頼性の確保: E-E-A-Tの徹底的な強化
3. 技術的な最適化: ページ表示速度とモバイル対応
4. 継続的な改善: データ分析に基づく戦略的アプローチ

成功の鍵は、AIの特性を理解した上で、ユーザーにとって真に価値のある情報を提供し続けることです。短期的な成果だけでなく、長期的なブランド価値の向上を目指すことが、持続可能なLLMO対策の基盤となります。]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[mainの最新変更を作業ブランチに取り込む]]></title>
            <link>http://izanami.dev/post/6b58cf91-bde9-4aaa-8de7-d3cc4d6d7077</link>
            <guid>http://izanami.dev/post/6b58cf91-bde9-4aaa-8de7-d3cc4d6d7077</guid><dc:creator>Nexyl</dc:creator>
            <pubDate>Wed, 30 Apr 2025 11:20:59 GMT</pubDate>
            <description><![CDATA[基本的にはPRを出したブランチでは、その後の作業はNG。

新しい作業は、PR中のブランチをコピーして別ブランチで進める。元のPRブランチが  にマージされたら、 に移動して  で最新状態を取得し、作]]></description>
            <content:encoded><![CDATA[基本的にはPRを出したブランチでは、その後の作業はNG。

新しい作業は、PR中のブランチをコピーして別ブランチで進める。元のPRブランチが  にマージされたら、 に移動して  で最新状態を取得し、作業中のブランチに戻り、 を する。

マージの例



全体の流れ

現在のブランチがAとしたら、このような流れになる。

1. ブランチAをコピーしたブランチBを作る
2. ブランチBで作業する
3. ブランチAがマージされる
4. main でプルする
5. ブランチBに移動
6. merge main でマージする

手順

ブランチAをコピーしたブランチBを作る



ブランチBで作業する

ブランチAがmainにマージされる（PRが通る）

mainに移動して最新状態をpullする



ブランチBに戻る



mainの内容を取り込む（mergeする）





例

今のブランチ名 feature/a とする

次のブランチ名の予定
feature/b

]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[GitHub で機密ファイルを誤って Push したときの安全な削除・復旧手順]]></title>
            <link>http://izanami.dev/post/4f7deacf-aea2-448f-acba-2e75c0554b2f</link>
            <guid>http://izanami.dev/post/4f7deacf-aea2-448f-acba-2e75c0554b2f</guid><dc:creator>Nexyl</dc:creator>
            <pubDate>Thu, 24 Apr 2025 17:21:19 GMT</pubDate>
            <description><![CDATA[うっかり GitHub にプッシュしてしまいそうなものとして、機密情報を含むファイル（API キーやトークンなど）があります。

これらの情報は、GitHub 上で公開されてしまうと、悪用される可能性]]></description>
            <content:encoded><![CDATA[うっかり GitHub にプッシュしてしまいそうなものとして、機密情報を含むファイル（API キーやトークンなど）があります。

これらの情報は、GitHub 上で公開されてしまうと、悪用される可能性があるため、特に注意が必要です。

機密情報（API キーやトークンなど）を含むファイルを GitHub に Push してしまった場合、単に GitHub 上で削除しても履歴には残り続けるため、適切な対処が必要です。本ドキュメントでは、誤って Push したブランチを安全に削除し、クリーンな状態で復旧するための手順をまとめます。

例として、以下のような状況を想定しています。

- 危険なブランチ名：old-sensitive-branch
- 安全なブランチ名：safe-recovery
- 機密ファイル名：secret.json

実行手順

流れとしては以下のようになります。

1. 現行ブランチのコピー作成 → 安全な作業用の新ブランチを確保するため
2. Git のインデックス（追跡情報）からファイルを削除する → 履歴に残さず、今後 Git に含まれないようにするため
3. .gitignore に機密ファイルを追加
4. GitHub 上の危険なブランチを削除
5. ローカルブランチ削除

1. 現行ブランチのコピー作成



2. Git のインデックス（追跡情報）からファイルを削除する

そして  の更新



3. GitHub 上の危険なブランチを削除



4. ローカルブランチの削除（任意）



その他の必須セキュリティ対策

- 誤って Push されたキーやトークンは 必ず無効化または再発行 する
-  などに保存されている情報も合わせて更新する

現在の安全状態チェックリスト

| 項目                             | 状態      |
| -------------------------------- | --------- |
| クリーンな新ブランチ作成         | ✅        |
| 危険ブランチの GitHub 上から削除 | ✅        |
| 機密ファイルの追跡解除           | ✅        |
|  追加済み            | ✅        |
| 機密情報の再発行                 | ⬜ 要対応 |

今後の再発防止策

-  や  などローカル専用ディレクトリは  で無視する
- 機密情報やトークンは Git に含めず、環境変数または Secret 管理ツールで管理する

このドキュメントは、機密情報を誤って Push してしまった際の再発防止と安全なリカバリを目的としてご利用ください。
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Cursor の料金体系。Enable usage-based pricing for premiun models]]></title>
            <link>http://izanami.dev/post/8f635291-37c4-484f-8d5e-143675dbd590</link>
            <guid>http://izanami.dev/post/8f635291-37c4-484f-8d5e-143675dbd590</guid><dc:creator>Nexyl</dc:creator>
            <pubDate>Tue, 01 Apr 2025 21:23:40 GMT</pubDate>
            <description><![CDATA[Cursor の料金体系、分かりづらいので整理してみました。Cursor を使い始めたとき、こんな疑問を持たれるかと思います。

- 「プランは色々あるけど、どれが自分に合ってるの？」
- 「Fast]]></description>
            <content:encoded><![CDATA[Cursor の料金体系、分かりづらいので整理してみました。Cursor を使い始めたとき、こんな疑問を持たれるかと思います。

- 「プランは色々あるけど、どれが自分に合ってるの？」
- 「Fast と Slow の違いって何？」
- 「従量課金って怖くない？」

そこで、Cursor の[公式ドキュメント](https://cursor.com/pricing)をもとに、料金プランや使用制限について、できるだけ分かりやすくまとめてみました（翻訳・要約にあたって一部表現を調整しています）。

プラン比較表（2025 年 4 月時点）

Cursor では以下のようなプランが用意されています。

| プラン         | ファストプレミアムリクエスト | スロープレミアムリクエスト | 補完   | その他                                                                 |
| -------------- | ---------------------------- | -------------------------- | ------ | ---------------------------------------------------------------------- |
| Hobby          | 月 50 回                     | 月 2000 回の補完まで       | 〇     | -                                                                      |
| Pro            | 月 500 回                    | 無制限                     | 無制限 | 毎日 10 回の o1-mini 使用                                              |
| Business       | Pro と同じ                   | 無制限                     | 無制限 | プライバシーモード、チーム請求、管理ダッシュボード、SAML/OIDC SSO 対応 |
| 無料トライアル | 150 回                       | 無制限                     | 無制限 | 14 日間の Pro トライアル                                               |

「Hobby で無料で始めてみて、物足りなければ Pro にアップグレード」みたいな流れが基本になるかと思います。

Fast？ Slow？実際どう違うの？

Cursor のリクエストには「Fast」と「Slow」の 2 種類があります。

- Fast：優先的に処理され、待ち時間が短い
- Slow：Fast クレジットが切れた後に利用される。使用量が多いと待ち時間が長くなる

Pro 以上のプランでは Fast クレジット（たとえば月 500 回）が付いており、それを使い切ると自動的に Slow に移行されます。

ただし、Slow でも十分使える印象です。どうしても待ちたくないときは、従量課金で Fast を追加できます。

従量課金ってどうなってるの？

正直、ここが一番分かりづらい。

従量課金では、以下のような仕組みが用意されています。

- Pro / Business プランのユーザーが対象
- Fast リクエストが足りなくなったら、自動で Slow に落ちるが、従量課金を有効にすると再び Fast を使える
- ダッシュボードからオン・オフを切り替え可能
- USD で上限設定が可能（使いすぎ防止）
- $20 相当の使用に達するか、月初 2 日〜3 日のいずれか早いタイミングで請求発生

「使いすぎないように、必ず上限設定はしておくと安心」です。

補足：ファストリクエストパッケージは廃止済み

:::warning
昔は「500 回パック」みたいなオプションもありましたが、今はもう新規購入はできません。今後はすべて従量課金ベースに統一されています。
:::

ファストリクエストはいつリセットされるの？

プラン登録時に決まった日が、毎月のリセット日になります。

例）3 月 23 日に登録 → 毎月 23 日にリセット。

追加購入してもリセット日は変わらない点に注意です。

チームプランの「500 プレミアムリクエスト」って共有なの？

共有ではありません。

各メンバーに月 500 回ずつ割り当てられる仕組みです。なので、チームの誰かが使いすぎて他の人の分がなくなる…みたいなことはありません。

再び高速リクエストにする

Cursor の Pro プランで月間 500 回の高速リクエストを使い切った後、再び高速リクエストを利用する方法は以下の通りです。

従量課金制（Usage-based Pricing）を有効にする

:::warning
ガンガン使っても一向に遅くならないなぁ、と余裕かましていたら、自動課金になってましたｗ
:::

Pro プランでは、500 回の高速リクエストを超えた場合でも、従量課金制を利用して追加の高速リクエストを行うことが可能です。 ​

Enable usage-based pricing for premiun models

![Enable usage-based pricing for premiun models](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/711ab4a6-151e-4f23-935f-4ac41f39f356/6da610a9-f1d8-41b7-88c3-d3b2f7359aec.webp)

Enable usage-based pricing for premiun models は、Cursor において「従量課金で高速（Fast）リクエストを追加購入できるようにする」設定です。

この設定をオンにすると、Pro プランで月 500 回の Fast リクエストを使い切ったあと、自動的に Slow に切り替わる代わりに、追加料金を支払うことで Fast リクエストを引き続き使えるようになります。

:::success
つまり、有効にすれば遅くならないが料金がかかる。
:::

利用量に応じて（たとえば 1 リクエストあたり数セント）課金されます。月々の支出上限も設定可能なので、「使いすぎて高額請求」にならないようにもできます。

逆にオフにしておくと、Fast の上限に達したあとは Slow リクエストに切り替わるだけで、追加課金は発生しません。

:::success
Cuosor の「Enable usage-based pricing for premiun models」をオフにして、リミットを$0 に設定しておくと低速になるけど、追加料金はかからない。
:::

- オン → Fast を使い続けられるが、使った分だけ課金される（上限設定は可能）
- オフ → Fast は月間上限まで。超えたら Slow に切り替わる。追加課金なし

設定方法：

1. Cursor のダッシュボードにアクセスします。​
2. 設定メニューから「Usage-based Pricing」のオプションを見つけ、有効にします。​
3. その下に、「Enable usage-based pricing for premiun models」のオプションがあるので、それも有効にします。
4. 追加課金をしたくない場合は、「Enable usage-based pricing for premiun models」を OFF にします
5. 必要に応じて、月々の支出上限を設定し、予期しない高額請求を防ぎます。​

注意点：

追加の高速リクエストには別途料金が発生します。料金詳細は Cursor の公式サイトで確認できます。 ​
支出上限を設定することで、予算内での利用が可能となります。​

Business プランへのアップグレードを検討する

より多くの高速リクエストや追加機能が必要な場合、Business プランへのアップグレードも一つの選択肢です。 ​

Business プランの主な特典：

- Pro プランと同様の高速リクエスト数 ​
- プライバシーモードの強制適用 ​
- チームの一括請求 ​
- 管理者向けの使用状況ダッシュボード ​
- SAML/OIDC SSO 対応 ​

OpenAI の API キーを利用する

Cursor では、独自の OpenAI API キーを使用して、直接リクエストを行うことも可能です。​ これにより、Cursor の基本プランを維持しつつ、API 使用量に応じた課金でサービスを利用できます。 ​

設定方法：

1. OpenAI の公式サイトで API キーを取得します。​
2. Cursor の設定で、取得した API キーを入力します。​
3. API キーを使用するオプションを有効にします。​

注意点：

API 使用量に応じた課金が OpenAI から直接行われます。​ 一部の機能（例：コードへの自動反映）が制限される場合があります。

まとめ

Cursor の料金体系は一見複雑ですが、ポイントは以下の通りです。

- 基本は「Fast → 上限 → Slow」
- 課金で Fast を追加できる（従量課金）
- Pro プランで十分な人が多い印象

「とりあえず Hobby で試して、ちょっと重い処理が増えてきたら Pro に移行」が良さそうですね。
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Git「ローカルの変更は、チェックアウトによって上書きされます」]]></title>
            <link>http://izanami.dev/post/077e02ab-a58d-4b68-9d2b-89e1e3fc6a6e</link>
            <guid>http://izanami.dev/post/077e02ab-a58d-4b68-9d2b-89e1e3fc6a6e</guid><dc:creator>Nexyl</dc:creator>
            <pubDate>Sun, 30 Mar 2025 15:23:36 GMT</pubDate>
            <description><![CDATA[ブランチ作業中に main を更新したいとき

開発中に  に他の作業がマージされたとき、現在のブランチにその変更を取り込みたい場合の安全な手順。

![ローカルの変更は、チェックアウトによって上書き]]></description>
            <content:encoded><![CDATA[ブランチ作業中に main を更新したいとき

開発中に  に他の作業がマージされたとき、現在のブランチにその変更を取り込みたい場合の安全な手順。

![ローカルの変更は、チェックアウトによって上書きされます](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/711ab4a6-151e-4f23-935f-4ac41f39f356/24df22e7-cc58-4a8e-8b2a-bb6a3e5440b7.png)

このダイアログは、ローカルに未コミットの変更がある状態で他のブランチにチェックアウトしようとしたときに表示されます。

「スタッシュしてチェックアウト」を選ぶことで、現在の作業内容を一時的に避難（stash）して、ブランチを安全に切り替えることができます。

![必要に応じてスタッシュ メッセージを提示する](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/711ab4a6-151e-4f23-935f-4ac41f39f356/89fc18b5-68ad-4e42-b1e4-24f15d976cf3.png)

次に、このメッセージが表示されたら、何かメッセージを入力してください。

1. 作業内容をスタッシュする

作業中のローカル変更がある場合、チェックアウト前にスタッシュする必要がある。



VSCode などの GUI では「スタッシュしてチェックアウト」を選ぶ。

2. main ブランチに移動して最新を取得



3. 作業ブランチに戻る



4. スタッシュを復元



スタッシュが適用され、元の作業内容が復元される。

5. 必要に応じてマージや rebase を実行

main からの変更を取り込みたい場合：



または履歴をきれいにしたい場合：



※ チームの運用方針に従って使い分ける。

補足：スタッシュの確認・削除



スタッシュが不要になったら自動的に削除されるが、手動で削除も可能：



この記事は、ブランチ整理中に遭遇した流れと対応をまとめたものです。
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[OpenAI の動画（画像）生成 AI「Sora」を使ってみた]]></title>
            <link>http://izanami.dev/post/061d8243-a323-46ee-b017-8f2cc04ed0fe</link>
            <guid>http://izanami.dev/post/061d8243-a323-46ee-b017-8f2cc04ed0fe</guid><dc:creator>Nexyl</dc:creator>
            <pubDate>Wed, 26 Mar 2025 10:16:55 GMT</pubDate>
            <description><![CDATA[OpenAI の動画生成 AI「Sora」とは？

動画・画像生成の [Sora](https://openai.com/ja-JP/sora/) は、OpenAI が開発した最先端の動画生成 AI ]]></description>
            <content:encoded><![CDATA[OpenAI の動画生成 AI「Sora」とは？

動画・画像生成の [Sora](https://openai.com/ja-JP/sora/) は、OpenAI が開発した最先端の動画生成 AI です。テキストのプロンプトから高品質な動画を生成できる技術で、映像クリエイターや開発者の間で注目を集めています。

OpenAI の動画生成 AI「Sora」は、テキストプロンプトから高品質な動画を生成する最先端の技術です。映像クリエイターや開発者の間で注目を集めています。現在、ChatGPT Plus および ChatGPT Pro のサブスクリプションを通じて利用可能です。

プロンプトに「映像クリエイターが mac で動画を作成しているシーン」と入力したところこのような動画が生成されました。

![映像クリエイターが mac で動画を作成しているシーン](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/711ab4a6-151e-4f23-935f-4ac41f39f356/0d25844c-c644-46c7-ac26-8e92626ff89d.jpg)

画像も簡単に出力できました。

![Soraで生成したイラスト](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/711ab4a6-151e-4f23-935f-4ac41f39f356/097482cc-ece2-496e-bd86-242984f992d1.jpg)


特徴

- テキストから動画を生成（例: "a dog surfing on the ocean"）
- 最大 1080p / 20 秒の動画を生成（Pro プラン）
- 動画のスタイルやカメラワークも細かくコントロール可能
- 自然な動きやリアルな表現力に優れる

テキストから動画を生成：ユーザーが入力したテキストプロンプト（例：「夕暮れ時の未来都市で空飛ぶ車」）から、リアルな動画を生成します。

高解像度・長時間の動画生成：最大 1080p の解像度で、最大 20 秒の動画を生成できます。

多様なスタイルとカメラワーク：動画のスタイルやカメラアングルを細かく指定し、希望のビジュアルを実現できます。

自然な動きとリアルな表現：高度な AI により、人物や物体の自然な動きやリアルな質感を再現します。

プランの違い

![2025/03/26更新](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/711ab4a6-151e-4f23-935f-4ac41f39f356/afad9a67-8abb-4bd4-aa18-35aff9581ef4.png)


| プラン名     | 料金      | 最大解像度 | 最大長さ | 同時生成数 | ウォーターマーク |
| ------------ | --------- | ---------- | -------- | ---------- | ---------------- |
| ChatGPT Plus | 約 $20/月 | 720p       | 10 秒    | 2          | あり             |
| ChatGPT Pro  | $200/月   | 1080p      | 20 秒    | 5          | なし             |

ChatGPT Plus プランでは、月額 20ドルで最大 50 本の優先生成が可能で、解像度は 720p、動画の長さは最大 5 秒です。

ChatGPT Pro プランでは、月額 $200 で最大 500 本の優先生成が可能で、解像度は 1080p、動画の長さは最大 20 秒となります。Pro プランでは、ウォーターマークなしの動画を生成できます。

使い方

ChatGPT にアクセス：ChatGPT Plus または Pro のアカウントでログインします。

![生年月日を入力します](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/711ab4a6-151e-4f23-935f-4ac41f39f356/dc25c4bb-179e-4000-b109-47d81cc6058f.png)

![ChatGPT Plus と、ChatGPT Pro で利用可能](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/711ab4a6-151e-4f23-935f-4ac41f39f356/69fb17ad-5685-4266-bbcc-51d307c8286c.png)

ChatGPT Plus なので右下に、ウォーターマークが入ってます。

Sora インターフェースを開く：Sora 対応のインターフェースに移動します。

テキストプロンプトを入力：生成したい動画の内容をテキストで入力します（例：「夕暮れ時の未来都市で空飛ぶ車」）。

動画の生成：数秒待つと、指定した内容の動画が生成されます。

プレビューとダウンロード：生成された動画をプレビューし、必要に応じてダウンロードします。

注意点

- 商用利用：商用利用を検討している場合、OpenAI の利用規約を確認する必要があります。
- ウォーターマーク：ChatGPT Plus プランでは、生成された動画にウォーターマークが付与されます。
- 動画の制限：プランによって、生成できる動画の長さや解像度に制限があります。
- 倫理的な考慮：Sora は高品質な動画を生成できますが、その能力を悪用しないよう注意が必要です。OpenAI は、著作権侵害や不適切なコンテンツの生成を防ぐための対策を講じています。 ￼

今後の展望

Sora は現在も進化中であり、今後さらなる画質向上や長尺動画への対応、音声との組み合わせなどが期待されています。

OpenAI による生成 AI の可能性を体験できる非常にユニークなプロダクトです。

参考リンク

- [OpenAI 公式サイト](https://openai.com)
- [ChatGPT プラン比較](https://chat.openai.com)
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Git チーム開発時の作業用ブランチの作り方]]></title>
            <link>http://izanami.dev/post/5202cf1c-4f22-40f5-94ba-1f7b16922c1e</link>
            <guid>http://izanami.dev/post/5202cf1c-4f22-40f5-94ba-1f7b16922c1e</guid><dc:creator>Nexyl</dc:creator>
            <pubDate>Sat, 22 Mar 2025 13:50:18 GMT</pubDate>
            <description><![CDATA[必要なコマンド表

ブランチを作るために、以下のコマンドを使います。よく使うので、覚えておくと便利です。表は横にスクロールできます。

| コマンド                     | 説明 ]]></description>
            <content:encoded><![CDATA[必要なコマンド表

ブランチを作るために、以下のコマンドを使います。よく使うので、覚えておくと便利です。表は横にスクロールできます。

| コマンド                     | 説明                                                     |
| ---------------------------- | -------------------------------------------------------- |
| git clone                  | リモートリポジトリをローカルに複製する                   |
| git remote -v              | リモートリポジトリの URL を確認する                      |
| git checkout -b ブランチ名 | 新しいブランチを作成してそのブランチに切り替える         |
| git pull origin main       | リモートの main ブランチの変更を取得してマージする       |
| git push origin ブランチ名 | ローカルの変更をリモートリポジトリにプッシュする         |
| git fetch origin           | 最新のリモートリポジトリ情報を取得（変更は適用されない） |
| git merge origin/main      | 取得した main ブランチの変更を現在のブランチに統合する   |
| git status                 | 現在の変更状況を確認する                                 |
| git log --oneline          | コミット履歴を簡潔に表示する                             |
| git diff                   | コミット間の差分を確認する                               |
| git add                    | 変更をステージングする                                   |
| git commit                 | ステージングされた変更をコミットする                     |
| git revert                 | 特定のコミットを打ち消す新しいコミットを作成する         |
| git reset --hard           | ローカルの状態を強制的にリセットする（※慎重に使用）      |

upstream

:::info
upstream はチーム開発や fork ベースの開発 でとても重要な概念ですが、状況によっては不要です。チームリポジトリに直接招待された場合、fork ではなく、GitHub 上で collaborator（共同編集者）として招待されている場合は、upstream（チームの本番リポジトリや fork 元のリポジトリ） は不要です。
:::

それでは、実際の作業手順を見ていきましょう。

1. clone する

リモートリポジトリをローカルに複製します。フォルダを作成しなくても git clone した際に自動的に作成されます。



:::warning
xxxx は、実際のパラメーターを入力してください。
:::

2. リモートリポジトリの情報を表示する

リモートの URL をチェックして、プッシュできるか確認します。これでリモートリポジトリ (origin) の URL を確認できます。これはリモートリポジトリに影響を与えないので実行しても問題ないです。



3. ブランチ作成

ブランチ dev を作成。main ブランチから dev を作成し、そのまま dev に移動します。



ブランチ戦略の補足

| ブランチ名  | 説明                                                                                           |
| ----------- | ---------------------------------------------------------------------------------------------- |
|       | 本番環境にデプロイされるコードを保持する安定版                                                 |
|        | 開発中のコードを集約する統合ブランチ。複数の feature/\ ブランチの作業結果がここにマージされる |
|  | 新機能や改善点を開発するためのブランチ。例: feature/login-page                                 |
|      | 作業途中（Work In Progress）の個人ブランチ。レビュー前の状態などに使用                         |

ブランチ名は意味のある名前にすると、他の開発者が意図を把握しやすくなります。以下は一例です。

| ブランチ名                  | 内容                                       |
| --------------------------- | ------------------------------------------ |
|         | ログインフォームの実装                     |
|         | README の誤字修正                          |
|      | ユーザーサービスのリファクタリング         |
|    | 緊急でアプリ起動時のクラッシュ修正         |
|  | 依存パッケージの更新                       |
|      | サインアップバリデーション作業中（未完了） |

ブランチ名に日本語は避け、スラッシュ（）でカテゴリと作業内容を区切るとわかりやすくなります。

4. main の最新の変更を dev に統合

main ブランチに新しい変更があった場合、それを dev ブランチに取り込む必要があります。作業ブランチが古い状態だと、マージ時にコンフリクトが起きやすくなります。リモートには影響せず、ローカルで最新の main を dev に統合するだけです。



4. dev に移動



5. dev の変更をリモートにプッシュ

ローカルで作業していた dev ブランチを GitHub 上のリモートにも作成します。他のメンバーと共有するには、リモートに push する必要があります。push はリモートに影響を与えますが、この段階ではまだ本番コードには関係しません。



6. main の最新の変更を取得（安全な方法）

もし main に新しい変更があれば、以下の方法でコンフリクトを避けるのが良いです。



-  → main の最新情報を取得（変更を適用しない）
-  → main の変更を dev に統合

git pull と git fetch + git merge の違い

-  は裏で  と  を自動で実行します。
- そのため、コンフリクトがある場合に自動でマージが始まり、対処しづらくなることがあります。
-  →  の手順であれば、最新の変更内容を事前に確認できるため、落ち着いてマージ作業ができます。

例えば以下のように作業できます。



6. 作業用のブランチを作成（例: 新機能追加）

作業ごとに新しいブランチを作ることで、機能ごとの変更を管理しやすくなります。dev や main に直接コミットせず、安全に開発を進めるための基本です。ブランチ名には何の作業かが分かるような名前をつけるのが望ましいです。



7. 作業完了後、dev にマージ

作業が終わったら、dev ブランチに変更を統合します。このタイミングで、他の作業ブランチの変更と合わせて検証できます。push することで、チーム全体の dev 状態を最新に保てます。



よくあるトラブルと対処法

コンフリクトが起きた場合は、該当ファイルに以下のような記号が表示されます。

<<<<<<<=======>>>>>>>

どちらの変更を残すか選択して、ファイルを編集した後  して  しましょう。



- 万が一、間違って  に直接 push してしまった場合は、 を使って変更を取り消すことができます。



または、履歴ごと戻す場合は  を使います（注意して使用してください）。



8. GitHub で PR を作成し、main に統合

GitHub 上での PR のポイント

- PR を作成するときは、以下のような情報を含めるとレビューがスムーズです。
  - 何を変更したか（What）
  - なぜ変更したか（Why）
  - 動作確認内容（How）

例：



- PR の作成後は、必要に応じて Reviewers や Assignees を設定しましょう。

PR 文章を提出する

一応、Notion などでPR依頼を伝えます。



マージされたら

Github の、main &gt; view all branches に移動。Your braches から削除します。

補足：CLI に不慣れな方向けのアドバイス

コマンドライン操作に不安がある場合は、以下のような GUI クライアントもおすすめです。

- GitHub Desktop
- Sourcetree
- Tower

また、現在の状態を確認したいときは以下のコマンドが便利です。



作業の前後にはこれらのコマンドで状況を把握すると、トラブルを避けやすくなります。
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Mac のシステムデータを減らす方法]]></title>
            <link>http://izanami.dev/post/1e529c0b-8477-4356-88c0-f566a778a106</link>
            <guid>http://izanami.dev/post/1e529c0b-8477-4356-88c0-f566a778a106</guid><dc:creator>Nexyl</dc:creator>
            <pubDate>Thu, 20 Mar 2025 19:32:27 GMT</pubDate>
            <description><![CDATA[結論から言うと、 の中身を削除しても問題ありません。これはアプリケーションのキャッシュを保存するディレクトリであり、削除してもアプリが再起動時に必要なキャッシュを再作成します。

ただし、以下の点には]]></description>
            <content:encoded><![CDATA[結論から言うと、 の中身を削除しても問題ありません。これはアプリケーションのキャッシュを保存するディレクトリであり、削除してもアプリが再起動時に必要なキャッシュを再作成します。

ただし、以下の点には注意してください。

削除しても安全なもの

一時ファイルやキャッシュファイル: ほとんどのアプリは削除後に再作成します。ブラウザのキャッシュ: Safari、Chrome、Firefox などのキャッシュが含まれていますが、削除しても動作に影響はありません。

Xcode のキャッシュ (com.apple.dt.Xcode など): Xcode を使っている場合、一時的にビルドの時間が長くなることはありますが、問題なく再生成されます。

削除すると影響がある可能性があるもの

未保存のデータ: 一部のアプリはキャッシュディレクトリを仮の保存場所として使うことがあります（特に画像編集ソフトや DAW など）。一部のアプリの設定ファイル: キャッシュではなく設定が含まれる場合、アプリの状態がリセットされる可能性があります。

安全に削除する方法

以下のコマンドでキャッシュが入ってるフォルダを Finder で開くことができます。



一括削除ではなく、特定のフォルダのみ削除する場合は、例えば Google や Xcode など、明らかにキャッシュであるものを削除します。

削除後に Mac を再起動してください。一部のキャッシュは使用中のため、削除が完了しないことがあります。再起動後に再作成されるため、問題がないか確認。

ターミナルで削除する方法

すべてのキャッシュを削除する場合は、以下のコマンドを使うこともできます。ただし、これを実行するとすべてのキャッシュが消えるため、アプリの初回起動時に遅くなることがあります。慎重に実行してください。



もし特定のアプリのキャッシュのみ削除したい場合は、以下のようにフォルダを指定します。



キャッシュ削除後に Mac の調子が悪くなった場合は、Time Machine のバックアップがあると安心です。]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[OpenNext で Vercel の代わりに格安でNext.js をデプロイする]]></title>
            <link>http://izanami.dev/post/6603ec7f-c952-43e1-97b2-ed808a47f398</link>
            <guid>http://izanami.dev/post/6603ec7f-c952-43e1-97b2-ed808a47f398</guid><dc:creator>Nexyl</dc:creator>
            <pubDate>Thu, 13 Mar 2025 14:33:40 GMT</pubDate>
            <description><![CDATA[[OpenNext](https://opennext.js.org/) は、AWS 上で Next.js アプリケーションをデプロイするためのオープンソースプロジェクト です。Next.js の A]]></description>
            <content:encoded><![CDATA[[OpenNext](https://opennext.js.org/) は、AWS 上で Next.js アプリケーションをデプロイするためのオープンソースプロジェクト です。Next.js の App Router を含む最新バージョンにも対応していて、Vercel なしで Next.js をスケール可能なサーバーレス環境にデプロイできるのが特徴です。

https://opennext.js.org

:::info
「Vercel 素晴らしいけど、ちょっとコストが高いなぁ」という方におすすめの内容となっています。
:::

💡 OpenNext の利用ケース

こういった方におすすめ。

✅ Vercel の料金が高い → 自前で Next.js のホスティングを構築したい  
✅ AWS をメインで使っている → Next.js を AWS サーバーレスで動かしたい  
✅ Next.js の Edge Functions を AWS 上で運用したい  
✅ App Router の機能を活かしつつ、Vercel 依存をなくしたい

🚀 OpenNext の特徴

1. AWS Lambda / Lambda@Edge / CloudFront に対応

- Next.js の各種機能（ISR、SSG、SSR、API Routes など）を AWS のサービスに最適化してデプロイ可能。
- Edge Functions もサポートし、パフォーマンスを向上。

Vercel との比較

| 機能                | Vercel     | OpenNext       |
| ------------------- | ---------- | -------------- |
| App Router サポート | ✅         | ✅             |
| ISR/SSG/SSR         | ✅         | ✅             |
| Edge Functions      | ✅         | ✅             |
| 自由なデプロイ先    | ❌         | ✅（AWS）      |
| コスト最適化        | ❌（高額） | ✅（AWS 次第） |

2. Vercel のようなエクスペリエンスを AWS 上で再現

Next.js の App Router / Pages Router に対応しつつ、CloudFront と Lambda@Edge で最適なレスポンスを提供。

3. Infrastructure as Code (IaC) 向けのサポート

AWS CDK, Serverless Framework, Terraform などで簡単にデプロイ可能。

4. ISR（Incremental Static Regeneration）のサポート

S3 と Lambda を活用し、動的にコンテンツを再生成可能。

5. 料金最適化

Vercel のような従量課金モデルではなく、AWS のコスト構造を活かして低コストで運用可能。

1. OpenNext のバックエンド構成

OpenNext は AWS Lambda だけでなく、Amazon ECS や AWS Fargate へのデプロイにも対応しています。特に、Lambda のコールドスタートの影響を避けたい場合には Fargate を利用する選択肢があります。

Fargate を使うと、コンテナを管理することなく、アプリケーションをスケーラブルに運用できるため、特に高トラフィックなアプリケーションに適しています。

2. OpenNext のキャッシュ最適化

OpenNext における ISR（Incremental Static Regeneration）のキャッシュ最適化は、S3 にキャッシュを保存し、CloudFront 経由で配信される仕組みです。 ヘッダーの設定がパフォーマンスに与える影響は大きく、適切な設定を行うことで、リクエストの応答時間を短縮できます。

また、stale-while-revalidate を活用しながらバックグラウンドでのキャッシュ更新が行われるため、ユーザーは常に最新のコンテンツにアクセスできます。

3. OpenNext のデプロイ戦略

現在の記事では  を利用したデプロイ方法が記載されていますが、実際の運用では Infrastructure as Code（IaC）の活用が重要です。

AWS CDK や Serverless Framework、Terraform などを用いることで、環境ごとのデプロイ管理が容易になり、コードとしてインフラを管理することができます。これにより、再現性のあるデプロイが可能になり、チーム全体での運用がスムーズになります。

4. OpenNext の制約や課題

OpenNext の制約として、AWS Lambda の 15 分の実行時間制限があるため、大規模な SSR を行う場合には不向きです。この場合、代替手段として AWS Fargate の利用が考えられます。

また、Vercel の Edge Functions とは異なり、OpenNext の Edge Functions は Lambda@Edge に依存しており、その影響で Node.js ベースの挙動になります。これにより、特定の機能やパフォーマンスに制約が生じる可能性があります。

Next.js (OpenNext) + Cloudflare Workers

この組み合わせについても検討してみましょう。

Cloudflare Workers は Next.js のサーバーレス環境として適しており、特に KV (Key-Value Storage) を使った動的キャッシュ は効果的。

Cloudflare Workers の KV (Key-Value Storage) を活用することで 動的キャッシュが効くので、Next.js の以下の機能が適切に動作します。

- PPR (Partial Prerendering) → 事前レンダリングと動的レンダリングのハイブリッド
- ISR (Incremental Static Regeneration) → 一部のページを動的に再生成
- Better Auth → 認証機能の強化

🛠 OpenNext のデプロイ方法

1 OpenNext のセットアップ



2 必要な環境変数を設定



3 デプロイ



まとめ

OpenNext は、Next.js のパフォーマンスを維持しつつ、AWS でコストを抑えながら運用したい人に最適な選択肢です。

- Vercel のコストが気になる → OpenNext で AWS にデプロイ
- Next.js の Edge Functions を AWS で使いたい → OpenNext が対応
- IaC で Next.js を管理したい → AWS CDK や Terraform と組み合わせて運用可能

AWS をメインに運用するなら、Vercel からの移行も視野に入るかもしれません。
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Figma で超簡単に Lottie アニメーションを作成する]]></title>
            <link>http://izanami.dev/post/f7572735-9ecd-4b53-9204-0c191c2be6ad</link>
            <guid>http://izanami.dev/post/f7572735-9ecd-4b53-9204-0c191c2be6ad</guid><dc:creator>Nexyl</dc:creator>
            <pubDate>Mon, 24 Feb 2025 14:47:45 GMT</pubDate>
            <description><![CDATA[Lottie とは？

Lottie は、Figma や、Adobe After Effects で作成したアニメーションを Web やアプリで利用できる軽量なフォーマットに変換できるライブラリです。]]></description>
            <content:encoded><![CDATA[Lottie とは？

Lottie は、Figma や、Adobe After Effects で作成したアニメーションを Web やアプリで利用できる軽量なフォーマットに変換できるライブラリです。JSON ベースのアニメーションファイルフォーマットを採用していて、さまざまなプラットフォームで再生することができます😄

今回の完成形はこちら。

![アニメーションの例](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/711ab4a6-151e-4f23-935f-4ac41f39f356/6dd8e194-fdd8-48a8-890b-d4ebebdde5ec.gif)

:::discovery
イラストをつなげてエクスポートするだけなので、初心者の方でもイラストがあれば10分程度でポチポチと作成できます。
:::

Lottie の特徴

Lottie は、以下のような特徴があります。

- 軽量なファイルサイズ
- 高品質なベクターアニメーション
- マルチプラットフォーム対応（iOS、Android、Web など）
- インタラクティブなアニメーション制御が可能
- スケーラブルなベクターグラフィックス

:::info
従来の GIF や動画形式と比較して、Lottie は高品質なアニメーションを維持しながら、ファイルサイズを大幅に削減できます。
:::

また、ベクター形式のため、どのような画面サイズでも鮮明な表示が可能です。開発者は JavaScript を使用してアニメーションの再生、停止、速度調整などを制御することができます。

Figma にインストールする

![Lottie download](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/711ab4a6-151e-4f23-935f-4ac41f39f356/61dea018-cfe1-48ec-ae29-788c5aad0002.png)

Figma に LottieFiles をインストールするには、以下の手順を実行します。LottieFiles の公式サイトにアクセスします。

https://lottiefiles.com/jp/plugins/figma

1. LottieFiles の公式サイトにアクセス
2. 「Figma にインストール」ボタンをクリック
3. Figma プラグインとして LottieFiles をインストール
4. Dev Mode プラグインもインストールして、より高度な機能を利用可能に

インストール後、Figma のプラグインメニューに LottieFiles が追加されます。Dev Mode プラグインは、アニメーションのプレビューやデバッグに役立つ機能を提供します。両方のプラグインを使用することで、より効率的な作業が可能になります。

Figma で オブジェクト を作成

Figma では、オブジェクトを作成することで、アニメーションさせたい要素を選択できます。

1. 新規 Figma ファイルを作成
2. フレームを作成（推奨サイズ：2360×500 など）
3. アニメーションさせたい要素をベクターオブジェクトとして作成
4. 各フレームにオブジェクトを配置

オブジェクトは可能な限りベクター形式で作成することをお勧めします。ベクターオブジェクトは、アニメーション時の品質を維持しやすく、ファイルサイズも抑えることができます。また、コンポーネントを活用することで、同じアニメーションを複数の場所で再利用することも可能です。

スマートアニメートで、オブジェクトをつなげる

![スマートアニメートでオブジェクトをつなげる](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/711ab4a6-151e-4f23-935f-4ac41f39f356/aeeb6cd2-98ba-4caa-a522-d191cf2e4a12.png)

スマートアニメートとは、2 つのフレーム間で同じレイヤー名を持つオブジェクトのプロパティの変化を自動的にアニメーション化する機能です。位置、サイズ、回転、色、透明度などの変更を滑らかなアニメーションとして表現できます。

1. 最初のフレームでオブジェクトの開始状態を作成
2. フレームを複製し、同じレイヤー名を持つオブジェクトの終了状態を設定
3. プロトタイプタブでフレーム間をつなぎ、トランジションを「Smart Animate」に設定
4. イージング（Easing）とデュレーション（Duration）を調整して動きを最適化

スマートアニメートを効果的に使用するためのポイント：

- レイヤー名を統一することで、フレーム間の対応関係が正しく認識されます
- グループ化されたオブジェクトも、グループ名を統一することでアニメーション可能です
- オートレイアウトを使用したフレーム間でもスマートアニメートが機能します
- オーバーレイ（Overlay）設定を使用すると、アニメーション後も元の位置を維持できます

右クリック → プラグイン → LottieFiles でエクスポート

![LottieFiles でエクスポート](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/711ab4a6-151e-4f23-935f-4ac41f39f356/d7d1062d-89c8-4089-ae67-12ef445c06a5.png)

オブジェクトを選択して、右クリック → プラグイン → LottieFiles でエクスポートします。

1. アニメーションが完成したら、フレームを選択
2. 右クリックしてプラグインメニューを開く
3. LottieFiles プラグインを選択
4. エクスポート設定を確認（フレームレート、サイズなど）
5. Lottie JSON ファイルとしてエクスポート

:::info
Gif、MP4、WebM、MOV、Lottie JSON のエクスポート形式が可能です。JSON 形式は、Lottie の 「Lottie JSON」からエクスポートできます。
:::

エクスポート時は、アニメーションの品質とファイルサイズのバランスを考慮してフレームレートを設定します。一般的な Web アニメーションでは 30fps が推奨されますが、より滑らかな動きが必要な場合は 60fps を選択することもできます。

Lottie にログインし、Projects にアップロード

![Lottie上で、プロジェクトが作成されている](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/711ab4a6-151e-4f23-935f-4ac41f39f356/990e9b48-3fcd-4121-ba17-c30ae1cefe52.png)

LottieFiles のアカウントを作成またはログインします。

1. LottieFiles のアカウントを作成またはログイン
2. 「Projects」セクションに移動
3. エクスポートした Lottie ファイルをアップロード
4. プレビューで動作確認
5. 必要に応じて設定を調整（ループ、速度など）

![様々なエクスポートに対応してる](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/711ab4a6-151e-4f23-935f-4ac41f39f356/4d4569ee-b170-472d-889a-c570a2c6d520.png)

LottieFiles のプラットフォームでは、アップロードしたアニメーションを管理・共有することができます。プレビュー機能を使用して、異なるデバイスやブラウザでの表示を確認できます。また、アニメーションの設定（ループ回数、再生速度、自動再生など）をカスタマイズすることも可能です。

CDN アセット機能

![CDN アセット機能](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/711ab4a6-151e-4f23-935f-4ac41f39f356/df21bf64-f071-4d92-8a7c-93792ddedb56.png)

LottieFiles の CDN（Content Delivery Network）設定画面では、アニメーションをウェブサイトやアプリで使用するための配信設定を行うことができます。

CDN を有効にすることで、アニメーションを様々なプラットフォーム（ウェブサイト、アプリ、SNS など）で効率的に使用することができます。特に大規模なトラフィックが予想される場合は、CDN の使用が推奨されます。

実装時の注意点

- アニメーションの最適化を忘れずに行う
- パフォーマンスを考慮したファイルサイズに抑える
- ブラウザやデバイスでの互換性をテスト
- アクセシビリティに配慮した実装を心がける

実装時は、アニメーションの複雑さとパフォーマンスのバランスを考慮することが重要です。特に、モバイルデバイスでの表示を考慮する場合は、ファイルサイズの最適化が必須です。また、アニメーションが自動再生される場合は、ユーザーの設定（省データモードなど）に応じて制御することをお勧めします。
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[シンタックスハイライト Shiki で美しいコードを表現しよう]]></title>
            <link>http://izanami.dev/post/6be28c9a-eb13-459b-a862-60121a778f1a</link>
            <guid>http://izanami.dev/post/6be28c9a-eb13-459b-a862-60121a778f1a</guid><dc:creator>Nexyl</dc:creator>
            <pubDate>Thu, 13 Feb 2025 16:24:14 GMT</pubDate>
            <description><![CDATA[シンタックスハイライト Shiki で美しいコードを表現しよう

ブログやドキュメントのコードが、もっと魅力的になったら素晴らしいですよね。シンタックスハイライト の Shiki を使えば、VS Co]]></description>
            <content:encoded><![CDATA[シンタックスハイライト Shiki で美しいコードを表現しよう

ブログやドキュメントのコードが、もっと魅力的になったら素晴らしいですよね。シンタックスハイライト の Shiki を使えば、VS Code と同じ美しいシンタックスハイライトを実現できます。今回は、この強力なツールの使い方をステップバイステップで解説していきますね。

https://shiki.matsu.io/guide/

セットアップから始めよう

最初のステップは、必要なパッケージのインストールです。npm を使って、簡単に Shiki をプロジェクトに追加できます。



Shiki を使い始めるには提供されているショートハンド関数を使用することです。これらの関数は必要なテーマと言語をオンデマンドで読み込み、メモリ内で自動的にキャッシュします。

では、実際にコードを書いていきましょう。

基本的な使い方

Shiki の基本的な使い方は、驚くほど簡単です。以下のサンプルコードを見てみましょう。



このシンプルなコードで、美しくハイライトされた HTML を生成できます。

 関数にコードスニペットと  および  を指定して渡すと、ページに埋め込むことができるハイライト済みの HTML 文字列が返されます。生成された HTML は各トークンごとにインラインスタイルが含まれているため、追加の CSS は不要です。

次は、より実践的な使い方を見ていきましょう。

ハイライターインスタンスの活用

Shiki には 2 つの重要な使い方があります。これまで見てきた  のようなショートハンド関数と、より柔軟な  を使用する方法です。それぞれの特徴を見ていきましょう。

ショートハンド関数の仕組み

ショートハンド関数は内部で WASM を使用し、必要なテーマと言語を自動的にロードします。これは便利である一方、毎回非同期処理が発生するため、パフォーマンスに影響を与える可能性があります。



ハイライターインスタンスの活用

大量のコードをハイライトする場合や、パフォーマンスが重要な場合は、 を使用してハイライターインスタンスを作成する方法がおすすめです。



このアプローチには以下のような利点があります：

- 初期化後は同期的に使用できるため、パフォーマンスが向上
- 必要な言語とテーマを明示的に指定できるため、バンドルサイズの最適化が可能
- 複数のコードブロックで同じインスタンスを再利用できる

:::warning
ハイライターインスタンスの作成は比較的コストの高い操作です。アプリケーション全体で再利用できるようにシングルトンとして管理することをおすすめします。
:::

実践的な使い方のヒント

Shiki をプロジェクトで効果的に使用するためのベストプラクティスをご紹介します。



よくあるエラーとその対処法

Shiki を使う上で、いくつかの一般的なエラーに遭遇するかもしれません。ここでは、主な問題とその解決方法を紹介します。

テーマが見つからないエラー



解決策： の呼び出し前に、必ずテーマが正しく指定されているか確認しましょう。また、テーマは動的にロードされるため、明示的にロードする必要があります。

言語が認識されないエラー



解決策：サポートされている言語識別子を使用しているか確認してください。必要な言語は初期化時またはあとから  メソッドでロードできます。

非同期処理の問題



解決策： は非同期関数なので、必ず  を使用してください。

Web プロジェクトでの活用法

Shiki は Web プロジェクトでも簡単に利用できます。CDN を使用する場合は以下のようにシンプルに実装できます。



パフォーマンスの最適化

Shiki を効率的に使用するためのポイントをご紹介します。

- ハイライターインスタンスはシングルトンとして再利用する
- 必要な言語とテーマのみを指定してバンドルサイズを最適化
- Web プロジェクトでは CDN の利用を検討する
- 大量のコードをハイライトする場合は、キャッシュの活用を検討する

まとめと次のステップ

Shiki を使ったシンタックスハイライトの基本を学びました。これであなたのコードは、より読みやすく、より美しくなるはずです。さらに深く Shiki を活用したい場合は、[公式ドキュメント](https://shiki.matsu.io/guide/)で高度な機能について学ぶことができます。

次は、実際のプロジェクトに Shiki を組み込んで、素晴らしいドキュメントを作成してみましょう。
]]></content:encoded>
        </item>
    </channel>
</rss>