はじめに Claude Codeをはじめとした AIコーディングエージェントが普及するなか、こんな疑問を持ったことはないでしょうか。 「.envは読むな」とシステムプロンプトに書いてある。でも、プロンプトインジェクションで言い方を変えれば読まれる、という話を聞いた。じゃあどうやって管理すればいいの？ この記事では、その疑問に正面から答えます。結論から言えば── 「禁止命令で守ろうとする」設計自体を捨てることが解決策です。 問題の構造：なぜ「禁止」だけでは防げないのか AIは「禁止」を意図で判断する LLM（大規模言語モデル）は、すべての入力テキストをフラットなコンテキストとして処理します。「システム指示」と「ユーザー入力」と「外部取得コンテンツ」を区別するよう設計されていますが、表現の巧みさによってその境界が曖昧になります。 これはアーキテクチャ上の制約であり、現時点では完全に解決されてい

はじめに こんにちは、ひるげです。 個人開発でWebアプリを作ったとき、「どこにデプロイすればいいんだろう？」と悩んだ経験、ありませんか？ AWSやGCPは高機能だけどコストが怖い。かといって無料のサービスは制限が気になる... この記事では、個人開発で使えるおすすめのデプロイ先をカテゴリ別に紹介します。実際に僕が開発中のアプリで採用した構成も公開するので、参考にしてみてください。 この記事の対象 本記事は、フロントエンドとバックエンドを分離する構成を前提としています。具体的には、React等のSPAをフロントに、Go/Node.js等のAPIサーバーをバックに置くような構成です。 以下のケースでは、ここまでの構成は不要です。 静的サイトのみ（ブログ、ポートフォリオ等） → GitHub PagesやCloudflare Pagesだけで十分 フルスタックフレームワーク（Rails、Nex

git alias を使ってコミットメッセージをAIに書かせる 最近はこれを git alias に入れて、コミットメッセージをゼロから書くことがほぼなくなりました。 aicommit = "!f() { COMMITMSG=$(claude --no-session-persistence --print 'Generate ONLY a one-line Git commit message in English using imperative mood. The message should summarize what was changed and why, based strictly on the contents of `git diff --cached`. DO NOT add an explanation or a body. Output ONLY the com

はじめに こんにちは！ みなさんは、コードレビューの負担に悩んでいませんか？マイクロサービスが増えるにつれて、レビュー対象のコードも増え続け、セキュリティやパフォーマンス、テストカバレッジなど、チェックすべき観点も多岐にわたるようになりました。レビュー待ち時間が開発速度のボトルネックになってしまう…そんな経験、ありませんか？ 私たちも同じ課題を抱えていました。AIレビューを導入していたものの、求める水準に達していなかったのです。そこで、Claude Code subagentsを導入し、専門特化したエージェントによるレビュー体制に刷新したところ、驚くほどレビューの質が向上しました。 この記事では、コードレビューのAI化について、その取り組みを共有します。 この記事で分かること 従来のAIレビューの限界と課題 Claude Code subagentsの設計と実装 GitHub Review

1. はじめに：この記事の前提と、私の定義する「Vibe Coding」 本題に入る前に、少しだけ私の立ち位置とこの記事の前提をお話しさせてください。 私はプログラマーとして約5年働いた後、現在はデータサイエンティストとしてAI構築とシステム構築を並行して行っています。 そのため、この記事でお話しする 「Vibe Codingは実プロジェクトで通用する」という結論は、あくまで私が身を置くデータサイエンスやAI開発の領域での話かもしれません。純粋なWebフロントエンド開発や、巨大なエンタープライズ系システムなど、他のIT分野でそのまま通用するかどうかは私自身テストしていません。 しかし、私がこの約6ヶ月間で試行錯誤し、Vibe Codingを使いこなすために工夫した「設計の考え方」や「AIとの付き合い方」には、きっと他の分野のエンジニアの方々にとっても役立つヒントがあるのではないかと思い、こ

Claude Codeの進化～Oikonさんと学ぶ、各機能の活かし方～(Findyさま): https://findy.connpass.com/event/385245/ X (Twitter) : https://x.com/oikon48 English ver: https://sp…

予備実験として「こういう傾向が見られた」と報告するのであれば有意義だと思います。ただ、交絡因子を分離できていない段階で「動的型付け言語が効率的」という因果的な結論まで踏み込むのは、少しミスリーディングではないかと感じました。 3. 測定しているものと結論の間にずれがある（構成概念妥当性の問題） 統計的な有意差の有無よりも、もっと根本的な問題があります。このベンチマークが測定しているものと、結論として主張していることが一致しているかという問いです。 「Claude Codeに向いているプログラミング言語」という問いに答えるには、「言語そのものの実装効率」を測る必要があります。しかし実際に測定されているのは、前節で述べたように「ブートストラップコスト＋ツール構成の試行錯誤＋実装コスト」の合算です。この合算値から「動的型付け言語が向いている」と結論づけるのは、測りたいものを測れていない可能性があ

昨今生成AIの進化は目覚ましく、私たちの働き方やビジネスモデルすら大きく変えようとしています。 特にソフトウェア開発では、今後以下のような点が大きく変化していくと予想されています。 コーディングの完全な自動化 コーディングコストの低下によるカスタムソフトウェアの台頭 AI Agent中心のユーザ体験への移行 一部では、1〜2年以内にほとんどのコードがAIによって書かれるようになるという予測もあり、プログラマに限らず「ソフトウェアエンジニアの仕事はなくなるのか」「カスタムソフトウェア中心の世界は本当に来るのか」は大きな関心ごととなっています。 実際にキャディ社内でもAIの活用が進んでおり、ChatGPTやGemini、NotebookLM等を使ったリサーチや分析はもちろん、Claude CodeやDevinを使った設計やコーディング、Slack BotとLLMを組み合わせたトイル削減など様々

突然ですが、こんな気持ちになったことありませんか？ 「ChatGPTって、なんとなく一般向けのツールっぽいんだよな」 「文章を書いてもらうくらいなら、Copilotで十分じゃない？」「API直接叩いた方がカスタマイズできるし」 エンジニアあるあるだと思います。APIが使えるからこそ、ChatGPTの公式UIをじっくり触ったことがないという方、意外と多いんじゃないでしょうか。 この記事では、そういった「なんとなく使いづらい」と感じる理由を一度整理した上で、知っておくと地味に得する使い道を3つ紹介します。 目次 エンジニアがChatGPTを敬遠する3つの理由 それでも知っておくと得する使い道 ① Advanced Data Analysis ── Jupyterより気軽にデータを触れる ② カスタムGPT ── チーム内のプロンプト資産を共有インフラにできる ③ 画像入力 × デバッグ ──