Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この30日間の記事では、無理なくスキルを習得し、最終的に自律的にコンテナをAWS上で運用できることを目指して、技術を整理していこうと思います。 第1週: コンテナ化の基礎とDockerの再確認 (Day 1 - Day 7) Day 1: 講座スタート！なぜ今、コンテナとDockerを学ぶべきなのか？ Day 2: Dockerの基本コマンド総ざらい：イメージとコンテナを徹底理解 Day 3: Dockerfileの書き方から学ぶ、軽量で堅牢なコンテナイメージの作り方 Day 4: ローカル開発環境をDocker Compos

登壇資料　HackFes.2025 | 日本ハッカー協会 https://hackfes2025.hacker.or.jp/

日本の大手メーカー、いわゆるJTCで課長になって4ヶ月が過ぎた。世の中でよく言われる中間管理職みは確かにあるって実感と、それを生じさせる要素や機序も少しは見えてきて面白いなって気持ちもあり、忘れないようにメモしておこうと思って。 基本情報 新卒で入社（22歳）→品質管理系の部署で係長クラス（33歳）→別の生産管理系の部署で係長クラス（37歳）→前の部署に戻って課長（39歳）、という流れ。 課の人数は自分を含めず20名いる。課には機能別ではなく、担当製品で分けた2つのグループがある。 巷間で言われる中間管理職み よく世の中で語られる中間管理職のつらさは以下のようなものがあるだろうか。 板挟みの立場：経営層と現場の間での板挟み、裁量が小さい割に責任が大きい。 心身への負担：労働時間の長さや業務負荷の高さ、プレッシャーの大きさ。 報酬面での不満：残業代のなさ、業務量や責任に対する報酬の低さ。 人

1. はじめに 開発プロセスにおける要件・設計のセキュリティレビューは、専門知識を要するため属人化しやすく、工数の増大が開発全体のボトルネックとなり得る課題です。 本稿では、私たちセキュリティチームがこの課題に対し、生成AIであるGeminiを活用してレビュープロセスを自動化し、工数を大幅に削減した技術的アプローチとその効果について報告します。 2. 対象読者 この記事は、特に以下のような課題を感じている方々に向けて書いています。 セキュリティレビューの工数増大や属人化に悩むセキュリティ担当者の方 セキュリティのシフトレフトを考えているエンジニアリングマネージャーの方 生成AIを活用した具体的な業務改善事例に興味があるすべての開発者の方 3. 現状のセキュリティ活動と課題 「1:10:100の法則」が示す通り、脆弱性の修正コストは開発の後工程になるほど増大します。故に、開発ライフサイクルの

LLMのプロンプトエンジニアリング ―GitHub Copilotを生んだ開発者が教える生成AIアプリケーション開発 作者:John Berryman,Albert Ziegler,服部 佑樹（翻訳）,佐藤 直生（翻訳）オーム社Amazon LLMアプリケーションを作ることがなかったとしても、業務でAIを活用する上で大前提を知っておくと役立ちそうということで、「LLMのプロンプトエンジニアリング」を読んだ。 実際に読んでみると、紹介されているLLMの特性を知っておくと、AIコーディングなどにもかなり役立ちそうで良かった。 たとえばこの本に載っている以下のような特徴は非常に参考になる。 テキストを一度しか読めず後戻りできない。そのため先に書かれた内容のみを考慮して後に繋げる 気が散りやすい。「うまくいけば」役立つかもしれない無用な情報でプロンプトを埋めないようにする 人間であるあなたが完全に

はじめに ご無沙汰しております。Cursor→Claudeとコスって開発PMを日々やっている中で、何を発信してよいやら迷走した1ヶ月でしたが復活しました。結局のところ、Tipsとプロンプトかなあというところに思い至りまして、そのまま使えずとも、「こんなことに使えるんだあ」という気付きになれば幸いです。 Claudeと言いつつ、ChatGPTでもGeminiでも行けるっちゃいけるんですが、Opusがやっぱり優秀なのでClaudeでやっています。 概要：ワークフロー図づくりで“詰む”前に── 「フロー図描いてって軽く言われたけど、そもそも何を聞けばいいんや……」――そんな若手の悲鳴を（また）聞きまして、プロンプトで一撃解決できんかと作ってみました。 「プロンプトはそのまんま載せてます。コピペして即生成AIに突っ込めば動くはず。 こんな感じのフローが簡単に作れるはずです 目次 なんでプロンプト？

こんにちは！PSIRT red team の kaworu と yusui です。4月に公開した脆弱性診断 with AIエージェント、はじめました。では、 AIエージェントを利用した脆弱性診断内製化について紹介しました。 約3ヶ月が経過し、記事で目標に掲げていた「開発のタイミングでAIエージェントによる脆弱性診断を実施し、結果に問題がなければそのままリリース」が実現し、開発チームでの脆弱性診断がついにひろがってきました！ 本記事では、実際に開発チームに展開されるまでと、工夫点をまとめました。 展開した脆弱性診断 with AIエージェント 4月の記事から、以下のような変化がありました！ AIエージェント……Cline から Roo Code へ 診断ナレッジを渡す方法……Memory Bank から freee 社内の MCP server へ Cline → Roo Code 4月の記

・要件定義 成果物は「経営者が参画する要求品質の確保」に記述されている 表4．3「役割分担と成果物例」にならい分類・表示している。 方向性と計画についてはこちら

Google⁠⁠、AIを使って非構造化テキストから構造化データを抽出するオープンソースPythonライブラリ「LangExtract」をリリース Googleは2025年7月30日、非構造化テキストから構造化データを抽出するオープンソースのPythonライブラリ「LangExtract」をリリースした。 Introducing LangExtract: A Gemini powered information extraction library -Google Developers Blog ✨Announcing LangExtract! ✨ Our new open-source Python library for information extraction, powered by #Gemini. ✅ Turn text into structured data ✅ Trace

はじめに 弊社エスマットでのファームウェア開発において、しばらく悩まされていた課題だった技術ドキュメントの整備を AI エージェントの Devin に任せてみました。 結果として、人手で 4 週間と見積もられた作業が、わずか 6 時間のレビュー作業で完了。合計で 1 万行を超える Markdown ドキュメントが作成され、ファームウェアの理解促進と AI コーディング精度の向上という目標を実現できそうなところまできました。 この記事では、Devin を活用したドキュメント整備の具体的なアプローチと、実際の運用で得られたノウハウを共有します。 背景：散在・陳腐化したファームウェアドキュメントの課題 ドキュメントの現状と課題 弊社製品であるスマートマットのファームウェアは、元々外注先で開発されたものを引き継いで開発を続けていました。外注先から引き継いだ時点で体系的なドキュメントは無かったようで

背景 近年、企業システムに対するサイバー攻撃は多様化・高度化しており、企業は日々新たな脅威への対応を迫られています。さらに、脆弱性の発見件数も年々増加傾向にあり、システムのリリース前後を問わず、潜在的な脆弱性をいかに早期に発見し適切に対策を講じるかが、事業継続や信頼性維持の観点からますます重要になっています。 一方で、脆弱性診断については多くの企業が外部ベンダーへ発注するケースが一般的ですが、脆弱性の増加やリリースサイクルの高速化により対応しきれないケースが増えつつあり、内製化への関心も高まっています。 こうした背景を踏まえ、当プロジェクトでは「脆弱性診断内製化ガイド」を作成しました。ガイドの作成にあたり、まず複数のツールを用いた技術検証で脆弱性診断の概要や概念、自動・手動診断の違いを整理し、それぞれの特性や有効性を明らかにしました。そのうえで、文献調査やアンケート、有識者・内製企業へのヒ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 皆さん、こんにちは！近年、開発ワークフローのあらゆる領域で、オープンソースツールの存在感が急上昇しています。商用ツールの代替として、より柔軟で費用対効果の高いオープンソース選択肢が次々と登場しているんです。 私自身、様々なオープンソースツールを試してきましたが、「無料なのにこんなに高機能でいいの？」と驚くことばかり。今回は特に注目度の高い15の有名ツールと、その優れたオープンソース代替を紹介します。プロユースから個人開発まで、コスト削減したい開発者から、自社サーバーでの運用を検討している企業の方まで、きっと役立つ内容になってい

ozawaです。暑い日が続いていますのでオフィス出社した際のランチは毎回同じ中華屋さんで冷麺セットを頼んでいます。たぶん冷麺野郎と裏で呼ばれていると思います。 AWS発のAIコーディングエージェント「Kiro」 インフラ屋さんのモチベーション 結論、「上流工程の品質が物を言う」 やったこと 要件・方式決めまではすんなりいく、ように見えた 個人的に気になった点 わりかし複雑な構成 漢気あふれる課題解決 そもそも何がいけなかった？ 曖昧な指示 考慮すべき観点の漏れ 前提条件のすり合わせ不足 インフラ屋さんがAIコーディングエージェントと仲良くなるために 一般的にリスクをはらむ箇所を抑える 開発環境やコーディング規約を統一する 既存ツール等でAIだけに依らない品質担保を意識する まとめ AWS発のAIコーディングエージェント「Kiro」 巷で流行りのKiroです。AIコーディングエージェントはい

毎日繰り返しやる処理は カスタムスラッシュコマンドで自動化する スラッシュコマンドとは あらかじめ登録した処理を実行できる 毎回長いプロンプトを書く必要がない 組み込みスラッシュコマンド /doctor Claude Codeのバグをチェック /review コードレビューをリクエスト https://docs.anthropic.com/ja/docs/claude-code/slash-commands カスタムスラッシュコマンドとは ユーザーが独自に登録した処理を実行できる 毎回命令している長いプロンプトは登録するのが便利 .claude/commands/コマンド名.mdに処理を記述 スコープを設定できる グローバル・プロジェクト・プロジェクトで自分だけ使う等 https://docs.anthropic.com/ja/docs/claude-code/slash-commands

生成AI（人工知能）はクラウドで提供されるものが主流だが、ローカルで動くものもある。ローカル生成AIのメリットや活用法を解説する。 「TkEasyGUI」は、筆者が開発しているPython用のGUIライブラリです。パラメータを細かく指定しなくても、見栄えの良いGUIアプリ（デスクトップアプリ）を手軽に作成できます。 ここでは、PythonとTkEasyGUI、そして、LLMの推論を行えるソフトウエアのOllamaを組み合わせて、図1のような「AIアシスタント」のデスクトップアプリを作成してみましょう。このアプリでは、画面上部のテキストボックスに、AIアシスタントに頼みたいこと（プロンプト）を書いて「送信」ボタンを押すと、画面下部のテキストボックスにLLMが生成した文章を表示します。なお、アプリの男性と女性の画像は、ChatGPTで生成したものです。

CSSには便利な単位がたくさんあります。よく使用する単位として絶対単位（pxなど）や相対単位（em, rem, %など）をはじめ、Gridの単位（fr）やビューポート単位（vw, vhなど）があります。いくつかの単位は使う場所が限られていますが、複数もしくはどこにでも使用できる単位もたくさんあります。 Webサイトやスマホアプリでフォントのサイズ、スペース、ポジション、FlexboxとGrid、要素の幅または高さに使用する場合、どのようにCSSの単位を選べばよいのかを紹介します。 What CSS length unit should you use? 以下は、そのフローの解説です。 フローの入り口は、下記のように分かれています。 ポジショニング、ディテール・エフェクトに適したCSSの単位 スペースに適したCSSの単位 フォントサイズに適したCSSの単位 FlexboxとGridに適したC

結論としてはとても良い。今後も継続していく。 自社のリポジトリに Claude Code Action を利用してレビューの仕組みを導入して、約1ヶ月が過ぎた。 この Claude Code Action (以降 LLM) によるレビューの何が良いのかというと「レビューを依頼するコストがゼロ」というのが一番良い。 人にレビューを依頼する場合、人の時間を奪う事と感じてしまう人が多い。そのため「ある程度出来てから」や「余裕ある時にレビューして」という依頼になりがちだが、LLM によるレビューの場合は 24/365 いつ依頼しても不機嫌になることもないし、厳しいレビューを依頼すれば厳しくレビューしてくれる。さらに早い。数分で終わる。 もちろん設計まで踏み込んでしっかりレビューしてくれるわけではないので、そこは人のレビューが入る必要がある。ただケアレスミスなどは、ほぼ確実に潰せる。 ちょっとコード

Wake Career 主催「夏の『りあクト！』勉強会〜教養としてのReact／React Nativeのすすめ〜」のセッションで使用したスライドです。

はじめに こんにちは！株式会社 Hacobu で Vista というプロダクトのフロントエンドエンジニアをしている cho です。 最近、社内で「Agentic Coding を眺める会」というイベントを開催しました。普段どんな感じで Claude Code を使って開発しているかを同僚に共有したところ、想像以上に反響があったんです。 特に、Custom slash commandsの部分で会議室がざわついて… 「え、そんなことできるの？」 「これめっちゃ便利そう！」 「自分でも作ってみたい！」 という声がたくさん上がりました 😊 イベント後、参加者から「これ、もっと詳しく知りたい！」「他のチームにも共有したい」という要望が続々と… そこで、実際に業務で使える Custom slash commandsをより多くの開発者に知ってもらいたいと思い、この記事を書くことにしました。 実際に社内

要件定義で意識していることを言語化したくなった こんにちは、のんピ(@non____97)です。 皆さんは要件定義で意識していることを言語化したくなったことはありますか? 私はあります。 いくつかのプロジェクトで要件定義をしてきましたが、改めて考えると、普段は感覚でやっている箇所も多くあったなと感じています。 そこで、改めて言語化することで、プロジェクトごとのブレを抑えたり、さらにどういった対応が必要なのかが整理できる予感がしてきました。 ということで、以降、要件定義で意識していることと要件の例を紹介します。 なお、「要件定義とは」や「要件定義の進め方」は語りません。書籍やインターネット上に先人たちが大量にアウトプットしてくださっているため、そちらを参照ください。 特にIPAが公開している「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」や「システム再構築を成功