【2026年3月最新版】コーディングが楽になったからこそ気をつけるべきセキュリティ - Qiita
はじめに こんばんは、mirukyです。 今回はいつものAWSシリーズとは少し毛色を変えて、AIコーディング時代のセキュリティについて書きます。 2025年から2026年にかけて、GitHub Copilot、Claude Code、Cursor、Cline、Amazon Q DeveloperなどのAIコーディングツールが急速に普及しました。コードを書くハードルが劇的に下がり、「プログラミング未経験でもアプリが作れる」時代が到来しています。 しかし、コーディングが楽になった裏側で、セキュリティリスクは確実に増大しています。 AIが生成したコードをノールックでコピペしていませんか？ AIが提案したパッケージを検証せずにインストールしていませんか？ ターミナルに貼り付けるコマンドの中身をちゃんと読んでいますか？ 本記事では、2026年3月時点の最新のセキュリティ事案・攻撃手法・業界動向を徹底
米国で話題のRAGのセキュリティ脅威についてまとめてみた - Qiita
はじめに こんばんは、mirukyです。 前回の記事「コーディングが楽になったからこそ気をつけるべきセキュリティ」では、AIコーディング時代のセキュリティリスクについてまとめました。 今回は、あの記事の中では深く触れられなかったRAG（Retrieval-Augmented Generation）システムのセキュリティ脅威に焦点を当てます。 RAGは今、企業のAI活用で最も導入が進んでいるアーキテクチャです。 社内ドキュメントをベクトルDBに取り込み、LLMに「自社の知識」を与える。Microsoft 365 Copilot、Amazon Q Business、社内チャットボット…どれもRAGを核としています。 私の記事でも、度々RAGを用いたナレッジベース構築を行ってきました。 しかし、米国のセキュリティ研究コミュニティでは、RAG固有の脅威が次々と報告され始めています。 2026年3月
コーディングガイドライン運用をAIで自動化し、レビュー知見を資産化する | CyberAgent Developers Blog
はじめに AmebaLIFE事業本部でWebフロントエンドエンジニアをしている湯本航基（@yu_3in）です。 本記事では、PRレビューコメントをもとにコーディングガイドラインを継続的に更新する仕組みについて紹介します。 最近は、AIの支援を受けながら実装を進めることが当たり前になってきました。 その一方で、チームの中にある判断基準やレビュー観点が整理されていないと、成果物の品質は安定しません。 今回取り組んだのは、その判断基準をレビューの中から継続的に回収し、ガイドラインとして育てていく仕組みです。 やりたかったのは、PRレビューの中にある判断基準を、継続的に再利用できる形にすることでした。 課題 背景にあった課題は、大きく2つありました。 レビュー知見がPRの中に埋もれて、チームの資産になりにくい ガイドラインを作っても、更新されずに形骸化しやすい もちろん、一般的なベストプラクティス
VitePressを用いてContext EngineeringとDocument Hostingを両立する - プププなテクブ
Coding Agent全盛の今、Docs as Code*1を用いたContext Engineeringが本格化しています。 最近OpenAIによって提唱された新たな概念・Herness Engineeringにおいても、もはやAIへ与えられる設計ドキュメント(コンテキスト)は前提として語られているほどです。 openai.com またエムスリー様においても、Docs as Codeの取り組みについてエントリが公開されていました。 www.m3tech.blog Docs as Codeを進める上で直面した課題 自分自身、とあるプロジェクトのテックリードとしてDocs as Codeを推し進めているのですが、その過程で直面した問題がありました。 Docs as Codeとして文書を作成するうえで、AIが好きに読み書きでき編集できる場所にドキュメントを置くことを考えると、必然的にアプリケ
DeepAgents × MCP で技術トレンドを”勝手に”調査してSlackに流すエージェントを作りました | SIOS Tech Lab
素の LangGraph でこれらを全部実装しようとすると、概算で 200行以上 のコードが必要になります。一方、DeepAgents なら 50行程度 で同等の機能が手に入ります。 とはいえ、DeepAgents は「全部入り」なので細かい制御がしづらい面もあります。使い分けとしては、プロトタイプは DeepAgents でサクッと作り、細かい制御が必要になったら素の LangGraph に降りる というアプローチがおすすめです。 🔌 MCP（Model Context Protocol）のおさらいMCP（Model Context Protocol） は、AI エージェントが外部ツールやデータソースにアクセスするための 共通プロトコル です。Anthropic が提唱し、現在は多くの企業・コミュニティがサーバーを公開しています。 LangChain エコシステムでは、langchai
Playwright + OWASP ZAP + Claude Code で E2E テストから脆弱性診断まで一気通貫でできるかやってみた
はじめに 最近、他チームのエンジニアが「Playwright で書いた E2E テストを OWASP ZAP に通して脆弱性診断をやってみた」という話を聞きました。 「E2E のシナリオってそのまま脆弱性診断にも使えるの？」 気になったので自分でも試してみました。その記録です。 やったこと（全体像） シンプルな Todo アプリを題材に、以下の流れで試しました。 1. Next.js で Todo アプリを構築 2. Playwright で E2E テスト（12シナリオ）を作成 3. バックエンドを FastAPI + MySQL に変更（Docker） 4. E2E シナリオを ZAP プロキシ経由で実行 → 脆弱性診断
証券システムと、それを取り巻く世界
個人投資家が「注文ボタン」を押すと、その注文は証券会社のシステムを経由して取引所へ送信されます。条件が合えばすぐに約定することもありますが、板の状況によっては約定せず注文が板に並び続けることもあります。ほんの一つの注文の裏側では、余力の仮拘束、取引所とのプロトコル通信、板寄せやザラバでのマッチング、清算機関（JSCC）でのネッティング、ほふりでの株式振替など、驚くほど多くのシステムが連携して動いています。 本書では、この一連の流れを「注文 → 約定 → 清算 → 決済(受渡)」の順にシステムエンジニアの視点で丁寧に整理しました。 ▼ 本書で得られる知識 ・証券取引を支えるプレイヤー(証券会社・取引所・JSCC・ほふり)の役割と全体像 ・注文管理システム(OMS)やフロント/ミドル/バックオフィスの構造 ・余力管理・与信チェック・冪等性など、システム設計上の勘所 ・DVP決済やネッティングな
Coding Agent時代の開発ワークフローについてのまとめ
こんにちは！逆瀬川ちゃん (@gyakuse) です！ 今日はCoding Agent時代の開発ワークフローについて、みんながやっているものからわたしがやっている手法までまとめて紹介していきたいと思います。 前回の記事 Claude Code / Codex ユーザーのための誰でもわかるHarness Engineeringベストプラクティス では、LinterやHooks、テスト戦略といった決定論的ツールでCoding Agentの出力を矯正するHarness Engineeringに特化しました。 今回はその上位にある問い、つまりハーネスは分かったけど全体としてどう開発を進めればいいのか、に答えます。プロジェクトの進め方、Agentとのコーディングテクニック、それを支えるインフラの3つの視点から2026年3月時点の状況を整理し、最後にわたし自身のワークフローも紹介します。 Agenti
Claude Codeのエージェントチームを使うだけで大抵のことが出来るようになった
エージェントチームでClaude Codeが賢くなった Claude CodeにAgent teamsが実装されてから、ずっと使っている。 複雑な要求も簡単な指示でこなせるようになってきた。 ドキュメント、コード、DBを網羅的に検索しながら実装案を考えても性能が落ちなくなった。 アップデートによってもっと良い方法が見つかったりするかもしれないが、現時点でのClaude Codeを使ったコーディングの進め方を書いておく。 ドキュメントとワークフロー ./claude-docs/ には セッションの記憶を保存する で書いた文書が大量にある。整理は諦めたので古い情報も結構ある。大きく仕様が変わった場合だけ手動で整理している。 また、Claude Codeが古い記述を見つけたら、そのときに/saveで自動更新される。 gitのworktreeで作業を開始するとき、ドキュメントにも新しいディレクトリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
