<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>i-know.dev ブログ</title>
    <link>https://www.i-know.dev/blog</link>
    <description>業務・個人開発で学んだこと、技術選定の理由、設計の意図、失敗と気づきを記録しています。</description>
    <language>ja</language>
    <lastBuildDate>Thu, 11 Jun 2026 19:02:23 GMT</lastBuildDate>
    <atom:link href="https://www.i-know.dev/feed.xml" rel="self" type="application/rss+xml"/>
    <item>
      <title>AI時代を見据えた AWSアーキテクチャ理解の向上①</title>
      <link>https://www.i-know.dev/blog/aieta-aws-yaunderstanding1</link>
      <guid isPermaLink="true">https://www.i-know.dev/blog/aieta-aws-yaunderstanding1</guid>
      <pubDate>Mon, 08 Jun 2026 10:12:04 GMT</pubDate>
      <description>AI時代を見据えたAWSアーキテクチャ理解の向上 みなさん、AIは使っていますか？ 大AI時代と言われる今、便利になったと感じる場面が増えた一方で、逆に「ここはまだ難しいな」「結局、自分で判断しないといけないな」と感じることもあります。 これはあくまで私の主観ですが、AIを使うことで開発そのもののハードルは下がったものの、システム全体をどう設計するかという部分の重要性は、むしろ以前より大きくなっているように感じています。 AIでコードは書ける。でも、その先はどうする？ 個人的には、Claude Codeを使うことで開発がかなり進めやすくなりました。 実際に、自分のサイトを作ったり、運営したりす</description>
    </item>
    <item>
      <title>Vercelセキュリティインシデントに巻き込まれた話と対応記録</title>
      <link>https://www.i-know.dev/blog/vercel-security-incident-2026</link>
      <guid isPermaLink="true">https://www.i-know.dev/blog/vercel-security-incident-2026</guid>
      <pubDate>Mon, 20 Apr 2026 04:57:49 GMT</pubDate>
      <description>何が起きたか 2026年4月19日、Vercelが公式にセキュリティインシデントを発表した。 内容は「Vercel社内の特定システムへの不正アクセス」。 ただし原因はVercel自体ではなく、サードパーティ製AIツールのGoogle Workspace OAuthアプリが侵害されたことだった。 そのツールを経由してVercelの内部システムにアクセスされた形。 影響を受けた可能性があるユーザーは数百人規模とのこと。 --- そもそも「OAuthアプリの侵害」って何？ セキュリティに馴染みのない人のために少し補足する。 普段、「Googleでログイン」「GitHubと連携」といったボタンを押して</description>
    </item>
    <item>
      <title>それでもAIを使う理由｜歴史的転換点の中で、SEは何を変えるべきか</title>
      <link>https://www.i-know.dev/blog/se-ai-coexistence-05</link>
      <guid isPermaLink="true">https://www.i-know.dev/blog/se-ai-coexistence-05</guid>
      <pubDate>Sat, 11 Apr 2026 14:24:55 GMT</pubDate>
      <description>はじめに ここまで、AI活用の難しさについて書いてきました。 - 実装はAI、責任は人間という非対称性 - どこまでAIに任せるかという委譲ライン - AIが得意なことと、人間が手放してはいけないこと - 個人利用と業務利用の間にある大きな差 ここまで読むと、むしろ「そんなに難しいなら、AIは慎重にしか使えないのでは」と感じるかもしれません。 でも、それでもなお思うのは、AIを使わないという選択肢はもう現実的ではないということです。 今回は、その理由と、ではSEは何を変えるべきなのかを考えてみます。 今回書きたいこと - なぜAIを使わない選択が難しいのか - AIによって何が変わりつつあるの</description>
    </item>
    <item>
      <title>業務でAIを使う難しさ｜個人では便利でも、組織ではそれだけでは回らない</title>
      <link>https://www.i-know.dev/blog/se-ai-coexistence-04</link>
      <guid isPermaLink="true">https://www.i-know.dev/blog/se-ai-coexistence-04</guid>
      <pubDate>Sat, 11 Apr 2026 14:24:54 GMT</pubDate>
      <description>はじめに AIは個人で使うととても便利です。 調べものも速いし、コードの叩き台も出るし、文章も整う。 一人で仕事を進めるうえでは、本当に助かる場面が増えました。 ただ、これをそのまま業務に持ち込むと、話は一気に複雑になります。 なぜなら、業務は個人の生産性だけで完結しないからです。 今回は、個人では便利なAIが、組織や現場の文脈に入った瞬間に難しくなる理由を整理してみます。 今回書きたいこと - 個人利用と業務利用の違い - 組織でAI利用が難しくなるポイント - 説明責任、再現性、引き継ぎの問題 - 現場で最低限必要になる視点 --- 業務でAIを使う難しさ 個人最適と組織最適は違う 個人で</description>
    </item>
    <item>
      <title>AIが得意なこと、人間が手放してはいけないこと｜速さに惹かれる時代だからこそ、役割分担を見失わない</title>
      <link>https://www.i-know.dev/blog/se-ai-coexistence-03</link>
      <guid isPermaLink="true">https://www.i-know.dev/blog/se-ai-coexistence-03</guid>
      <pubDate>Sat, 11 Apr 2026 14:24:54 GMT</pubDate>
      <description>はじめに AIを使っていると、できることの多さに驚かされます。 調査も速い。整理も速い。コードも書く。説明もする。 だからこそ、ともすると「人は何を担うべきなのか」が曖昧になりがちです。 今回は、AIが得意なことと、人間が最後まで手放してはいけないことを整理してみます。 今回書きたいこと - AIが強い領域 - 人間が持つべき領域 - 役割分担を間違えたときに起きること - AI時代に人間の価値がどこへ移るのか --- AIが得意なこと、人間が手放してはいけないこと AIが強いのは「広く、速く、叩き台を出すこと」 AIの強みを一言で言うなら、広く情報を扱い、速く形にすることだと思います。 情報</description>
    </item>
    <item>
      <title>どこまでAIに任せるか｜委譲ラインを決めないと、便利さが不安に変わる</title>
      <link>https://www.i-know.dev/blog/se-ai-coexistence-02</link>
      <guid isPermaLink="true">https://www.i-know.dev/blog/se-ai-coexistence-02</guid>
      <pubDate>Sat, 11 Apr 2026 14:24:54 GMT</pubDate>
      <description>はじめに 前回は、実装はAI、責任は人間という非対称性について整理しました。 AIは速い。しかもそれっぽく正しいものを返してくる。 だからこそ、任せた方が前に進む一方で、任せきるのは怖い。そんなジレンマが生まれます。 では、その中で実務的に重要になるのは何か。 それが、どこまでAIに任せるかを決めることです。 今回は、業務でAIを使うときの委譲ラインについて考えてみます。 今回書きたいこと - なぜ委譲ラインが必要なのか - AIに任せやすい作業と任せにくい作業 - 実務で線引きするときの考え方 - 完璧な正解がない中で、どう現実的に運用するか --- どこまでAIに任せるか 一番危ないのは「</description>
    </item>
    <item>
      <title>AIバイブコーディングのジレンマ｜実装はAI、責任は人間という非対称性</title>
      <link>https://www.i-know.dev/blog/se-ai-coexistence-01</link>
      <guid isPermaLink="true">https://www.i-know.dev/blog/se-ai-coexistence-01</guid>
      <pubDate>Sat, 11 Apr 2026 13:59:35 GMT</pubDate>
      <description>はじめに この文章について これは「SEとAIの共存を模索する記録」シリーズの第1回です。 AIを開発業務に取り入れる中で感じている違和感や難しさを、現場目線で整理していくシリーズとして書いています。 今回のテーマは、AIの実装速度と、人間が負う責任の重さが釣り合っていないという問題です。 こんな方に向けて書いています - 業務でAIを使い始めたエンジニア - AIに実装を任せつつ、不安や違和感もある人 - AI活用を進めたいが、品質や責任分界に悩んでいる人 - AI時代にSEの役割がどう変わるのか考えたい人 今回書きたいこと - なぜAI活用にジレンマが生まれるのか - 「実装はAI、責任は</description>
    </item>
    <item>
      <title>Axiosのサプライチェーン攻撃について</title>
      <link>https://www.i-know.dev/blog/axios-about</link>
      <guid isPermaLink="true">https://www.i-know.dev/blog/axios-about</guid>
      <pubDate>Mon, 06 Apr 2026 07:12:34 GMT</pubDate>
      <description>Axiosとは何か、今回の問題の概要、今取るべき確認手段と検知時の対応 2026年4月時点の整理 はじめに 2026年3月末、JavaScript界隈で非常に大きなインシデントが発生しました。 広く使われているHTTPクライアントライブラリ Axios のnpm配布物が一時的に改ざんされ、悪意のあるパッケージが正規アップデートを装って配布されたのです。 これは単なる「ライブラリの不具合」ではありません。 開発環境・CI/CD・ビルド基盤そのものが攻撃対象になるサプライチェーン攻撃 であり、企業や開発組織にとっては信用に直結する重大事です。 本記事では、まずAxiosが何かを整理したうえで、今回</description>
    </item>
    <item>
      <title>AIが頼んでもいない修正を勝手にしてしまう問題の対策用テンプレート</title>
      <link>https://www.i-know.dev/blog/ainmoinotfixshiteshimauproblem-template</link>
      <guid isPermaLink="true">https://www.i-know.dev/blog/ainmoinotfixshiteshimauproblem-template</guid>
      <pubDate>Wed, 01 Apr 2026 05:43:01 GMT</pubDate>
      <description>AI既存改修運用・最強テンプレート集 対象: 既存システムの機能追加 / 改修 / バグ修正 目的: AIによる解釈違い・勝手な修正・不要な修正を抑え、最小差分で安全に進める 想定利用: VS Code Copilot（Claude Sonnet系） + Gemini系での壁打ち / レビュー --- はじめに 既存システム改修でAIを使うときに最も危険なのは、AIの精度不足そのものではありません。 本当に危険なのは、AIが勝手に判断してよい領域が曖昧なまま実装に入ること です。 そのため、本テンプレートの思想は一貫しています。 - AIに自由に考えさせすぎない - 推測で埋めさせない - 変</description>
    </item>
    <item>
      <title>AIが頼んでもいない修正を勝手にしてしまう問題</title>
      <link>https://www.i-know.dev/blog/ainmoinotfixshiteshimauproblem</link>
      <guid isPermaLink="true">https://www.i-know.dev/blog/ainmoinotfixshiteshimauproblem</guid>
      <pubDate>Wed, 01 Apr 2026 05:27:10 GMT</pubDate>
      <description>AIに既存システム改修をさせると勝手な修正が増える理由と、防ぐための進め方 既存システムの改修や機能追加、バグ修正をAIに手伝わせると、こちらが意図していない修正まで入ってしまうことがあります。 仕様を読ませ、コードを読ませ、プランを立てさせてからレビューし、実装に入る。流れとしてはきれいに見えても、実際には「勝手な修正」や「不要な修正」が混ざるケースは少なくありません。 私も以下のような手順で進めていました。 1. を読み込ませる 2. ソースコードを読み込ませる 3. プランニングさせる 4. プランニングレビューを行う 5. 実装させる この流れ自体は間違っていません。 ただ、既存システ</description>
    </item>
    <item>
      <title>2026年3月時点で見るAIサービス事情</title>
      <link>https://www.i-know.dev/blog/ai_service_trends_as_of_march_2026</link>
      <guid isPermaLink="true">https://www.i-know.dev/blog/ai_service_trends_as_of_march_2026</guid>
      <pubDate>Fri, 27 Mar 2026 02:21:19 GMT</pubDate>
      <description>2026年3月時点で見るAIサービス事情 どこが最強かではなく、分野ごとに「今よく名前が挙がるAI」を整理してみる AIサービスの話をしていると、どうしても「結局どれが一番強いの？」という流れになりがちです。 ただ、2026年3月現在の状況を見ると、実態はもう少し複雑です。 いまは1つのAIが全分野を完全に制するというより、用途や分野によって“よく選ばれるサービス”が分かれている印象があります。 そのため本記事では、「どこが最強か」を断定するのではなく、この分野ではこのAIが人気・この用途ではこのAIが使われやすいという温度感で整理してみます。 --- まず前提：AIは“万能一本化”より“用途</description>
    </item>
    <item>
      <title>iOSアプリアイコン生成ガイド</title>
      <link>https://www.i-know.dev/blog/ios-app-icon-generation-guide</link>
      <guid isPermaLink="true">https://www.i-know.dev/blog/ios-app-icon-generation-guide</guid>
      <pubDate>Thu, 22 Jan 2026 07:46:19 GMT</pubDate>
      <description>iOSアプリアイコン生成ガイド このドキュメントは、完成したアイコン画像から iOSアプリ用の App Icon（Assets.xcassets）を生成する方法をまとめたものです。 --- 前提 - すでに 1024×1024 の元画像があること - 角丸・影・光沢は 画像側では付けない - iOS（Xcode）向けに最適化された出力を得たい --- 推奨ツール（最優先） App Icon Generator 🔗 https://appicon.co/ 特徴 - 1024×1024画像を1枚アップロードするだけ - iOS用の 全サイズを自動生成 - AppIcon.appiconset を</description>
    </item>
    <item>
      <title>『外出先のiPhoneから自宅MacのClaude Codeを操作する方法』を挑戦した際のハマりポイント</title>
      <link>https://www.i-know.dev/blog/iphone-remote-claude-code-on-mac</link>
      <guid isPermaLink="true">https://www.i-know.dev/blog/iphone-remote-claude-code-on-mac</guid>
      <pubDate>Mon, 12 Jan 2026 06:59:39 GMT</pubDate>
      <description>はじめに 外出先のiPhoneから自宅MacのClaude Codeを操作する方法 こちらの記事を参考に、実際に自分の環境でも試してみました。 構成自体はとても分かりやすかったのですが、実際にやってみると すんなり接続できずにハマったポイント があったため、 この記事では「自分がどこで詰まり、どう解決したか」をまとめています。 同じように NeoServer × Tailscale × macOS 構成で試す方の参考になれば幸いです。 --- ハマりポイント 記事内の 「3. NeoServerでSSH鍵を生成・配置」 の手順をそのまま実行しました。 ある程度設定も済み、 - ホスト設定 - </description>
    </item>
    <item>
      <title>ClaudeCodeを使ったAI駆動型開発</title>
      <link>https://www.i-know.dev/blog/development2026f</link>
      <guid isPermaLink="true">https://www.i-know.dev/blog/development2026f</guid>
      <pubDate>Wed, 31 Dec 2025 15:02:23 GMT</pubDate>
      <description>Claude Codeを使ったAI駆動型開発をしてみて 2026年最初のブログ。 振り返ってみると、2025年はAIが爆発的に進化した1年だったと思う。 Claude Code が台頭し始めたあたりから、数日おきに各社のAIがアップデートされ、 &gt; 「すげーな…」 と感心したと思ったら、 数日後には別の会社がさらに「すげー」アップデートを出してくる。 そんなサイクルが延々と続いた、AI関連のニュースがとにかく賑やかな一年だった。 --- Claude Codeを使い続けて感じたこと そんな中でも、個人的には Claude Code をかなり愛用している。 途中で「ちょっと微妙では？」みたいな時</description>
    </item>
    <item>
      <title>App Store 申請を初めて行うときの手順まとめ（完全ロードマップ）</title>
      <link>https://www.i-know.dev/blog/first-apple-store-application</link>
      <guid isPermaLink="true">https://www.i-know.dev/blog/first-apple-store-application</guid>
      <pubDate>Fri, 12 Dec 2025 07:51:56 GMT</pubDate>
      <description>以下の 10 ステップを順に進めれば 初回申請が完了できる 形にしています。 --- ✅ STEP0：事前に必要なもの まずは “申請のために最低限必要なもの” を揃えます。 必要なもの一覧 * Apple ID * Apple Developer Program（年額 11,800円 程度）登録済み * アプリ名（英語名 + 日本語名） * アイコン画像（1024×1024） * スクリーンショット（iPhone / iPad / macOS など） * プライバシーポリシーのURL * Xcode（最新版） --- ✔ STEP1：Apple Developer Program に登録 h</description>
    </item>
  </channel>
</rss>