はてなブックマーク

0. はじめに：なぜ「Skillsそのもの」を議論するのか 本記事では、Codex Skillsを勉強会で実際に使ってみた体験をもとに、 エンジニアと非エンジニアの間でどのような認識のズレが生まれたのかを整理しました。 あわせて、Skillsを「チームで仕事のやり方を共有する仕組み」として使うために、 どのような前提や設計が必要なのかを考察しています。 Skills は、AI エージェントに対して 「仕事のやり方」をまとめて教えるための仕組み です。 一方で、実際に勉強会などで触れてみると、 Prompt と何が違うのか分からない いつ Skills を作るべきか判断できない 「Skill を設計する」と言われても、設計対象が見えない といった声も多く聞かれました。 本記事では、社内勉強会（第10回「AIハッカソン・黙々勉強会」）を通じて見えてきた 「エンジニアが考える Skills の捉

はじめに：なぜランサムウェア対策としてリスク分析が必要なのか ランサムウェアは、技術的な巧妙さとともに事業への影響の大きさが問題となるサイバー脅威です。 EDRの導入、バックアップの取得、復旧訓練の実施といったランサムウェアへの対策は、多くの企業ですでに進められています。一方で、「どの情報資産がランサムウェアに感染すると事業に致命的な影響が出るのか」「どの侵入経路が実際に成立しやすいのか」「被害発生時に本当に復旧できるのか」といった問いに、体系的に説明できるケースは多くありません。そこで共通して見えてくる課題があります。それは、対策は講じているものの、どこを優先して守るべきかが整理されていないという点です。 ランサムウェア攻撃は、単一の対策で防げるものではありません。 攻撃者は複数の侵入口を使い分け、侵入後も環境に応じて手法を変えながら、最も効果の高い情報資産を狙います。そのため「対策を導

はじめに この記事は、MEKIKI X AIハッカソンもぐもぐ勉強会 Advent Calendar 2025の21日目です。 今回は、ちょっと高度なGitHub Copilotの使い方をご紹介します！ GitHub Copilotを使い始めると、まずはインライン補完やCopilotチャットでの質問、コード説明といった基本機能から試される方が多いと思います。これだけでも十分便利ですが「GitHub Copilotが外部ツールと連携するとどんな使い方ができるのか」「カスタムエージェントを定義すると振る舞いはどう変わるのか」といった点は実際に触れてみないとなかなかイメージしにくいところです。 そこで、GitHub CopilotがMCP連携とカスタムエージェント機能を通じて、外部ツールとどのように連携し、チャットの振る舞いをどう変えられるのかについて、実際に試してみた内容をご説明します。 題材

はじめに データエンジニアをやっておりますTaichiです。 先日、MinIO の Docker イメージが公式から配布停止になりました。 Issue コメントにもある通り、コミュニティ版は今後「ソースコード配布のみ」で、自分でビルドしてねという方針に変わっています。 ちょっとした手元の検証環境にMinIOを使っていた自分としては、docker runで簡単に立ち上がり、Amazon S3 互換 APIで操作できるOSSが欲しいなと思っています。 そういうわけで、MinIO 以外の OSS オブジェクトストレージをいくつか調べてみたところ、 RustFS が手軽に利用できそうだったので、今回は RustFS を試してみました。 RustFSの主な特徴 1. Rust 製 & 高性能 その名の通りRustFSはRustで実装されており、メモリ安全性とパフォーマンスを売りにしている。 公式 R

こんにちは、MEKIKI X AIハッカソンもくもく勉強会の12日目を担当するYokoiです！ 普段はモダナイゼーション案件で生成AIの活用支援をしています。プライベートではドライブとサウナにハマっています。 今日は、ローカル環境で完結するRAG構築について書いてみました。 2025年10月22日、ついに LangChain v1 がリリースされました。 API 設計やエージェント機能が大きく進化しましたが、ネット上にはまだ v0 系の情報が多く、最新仕様で実装しようとすると意外とつまずきがちです。 そこで本記事では、LangChain v1 と Ollama を使い、Windows ラップトップだけで完結する「完全ローカル RAG」をご紹介します。 外部クラウドへデータを送信しない構成なので、セキュリティ規定が厳しい組織でも安心して検証できます。「最新の LangChain をキャッチア

この記事はJapan AWS Top Engineers Advent Calendar 2025のDay9 の記事です。 対象読者 Amazon Web Services（AWS）でバックアップ戦略を検討している方 ランサムウェア対策としてのバックアップ設計を検討している方 AWS Backupの論理的エアギャップボールト（Logically Air-Gapped Vault）に興味がある方 マルチアカウント構成でのバックアップ管理を検討している方 はじめに 本記事ではランサムウェア対策としてのバックアップ戦略をご紹介します。 「バックアップを取っていれば安心」という時代は終わりました。現代のランサムウェア攻撃は、バックアップデータそのものを標的にします。本記事では、Veeamが提唱する「3-2-1-1-0ルール」をベースに、AWSでどのようにバックアップを保護するかを、2025年にリリ

はじめに アジャイル開発では「チームワーク」が成果の鍵を握ります。 しかし、チームの中に高い技術スキルを持っていても、協調性に欠けるメンバーがいると、プロジェクトは一気に難航します。 そうした存在は「ブリリアントジャーク（Brilliant Jerk）」と呼ばれます。 私自身、スクラムマスターとして、まさにそのような状況に直面したことがあります。 本記事では、そのときの経験と、そこから得た教訓を紹介します。 ※ご紹介する内容はわかりやすく一般化したもので、実在のプロジェクトや人物とは一切関係ありません。 ブリリアントジャークとは何か ブリリアントジャークとは、優秀だが厄介な人を意味します。 彼らは知識も技術も豊富ですが、他者への配慮や共感が欠け、結果としてチーム全体の心理的安全性を壊してしまうことがあります。 アジャイルでは、透明性・協働・自己組織化が重要です。 しかし、コミュニケーション

LangChain v1.0 主な新機能と変更点 1. create_agent: 高度なエージェント開発を簡単に LangGraphで提供されていた create_react_agent と同様の機能が、LangChain v1.0の langchain.agents.create_agent として統合・強化されました。これにより、Tool Calling/MCPを利用した高度なエージェントをLangChainのみで簡単に作成できるようになりました。 from datetime import datetime from zoneinfo import ZoneInfo from langchain.agents import create_agent from langchain.tools import tool @tool def get_current_time(timezone

前置き はじめまして！株式会社NTTデータグループの技術革新統括本部AI技術部でSmart AI Agent®︎のエンジニアをしている岸川です。 今回は、GPUクラウドサービス「Runpod」について、実際に研究と仕事で活用してきた経験をもとに紹介します。「ちょっとGPU使いたいだけなのに...」という悩みを持つ方に向けて、Runpodの魅力と具体的な使い方を解説していきます！ はじめに 機械学習の実験や開発をしていると、こんな悩みに直面していませんか？ Google Colabユーザーの悩み 特に大学院生の方は、こんな経験があるのではないでしょうか。 Colab Proに課金しているけど、実行時間制限で長時間の学習が中断される... もっと高性能なGPUを使いたいけど、さらに課金するのは躊躇する 研究の締め切り前に限って、リソース制限が厳しくなる気がする... クラウド初心者の壁 Azu

ブログ執筆者倍増計画 NTT DATAでは、2025年4月からZennでの技術ブログを始めました。 これまでに約140記事が投稿され、比較的盛り上がっていると思うのですが、もっと執筆者を増やしたいけどどうしたらいいかなと広報部の方から聞かれたりしています。 「なんで俺に聞くねん」と思ったりもしたのですが、一説によると、技術ブログを始めることになったきっかけは私が社長に言った一言だったらしく、私は知らない間にブロガーとして認知されていたようでした。 そこで、 さすがに責任の一端を感じ、 せっかく自由にブログを書ける環境を整えてもらったので、技術ブログを書いたことがない人に向けて「好きな技術を紹介する」というテーマで記事を書く方法をアドバイスしようと思います。もちろん、書き方は他にもいろいろありますので、あくまで一例として、使えるところがあれば使ってやる程度の気持ちで読んでください。 技術ブロ

デイリースタンドアップ、スプリントプランニング、レトロスペクティブ。スクラムのフレームワークは完全に導入した。チームは毎日15分のスタンドアップをしているし、2週間ごとにふりかえりとカイゼンアイテムの特定をしている。でも、何かが違う。現場は相変わらず「忙しい」と言い続け、部門間の壁は高いままで、意思決定のスピードは上がらない。 アジャイルやスクラムを始めたばかりのチームや組織において、このような状況に心当たりがあるのではないでしょうか。問題は、フレームワークそのものではありません。 ここで私たちが直面しているのは、技術的課題と適応課題を取り違えているという、より根本的な問題です。 技術的課題と適応課題 この概念は、ハーバード大学のロナルド・ハイフェッツ氏が提唱したリーダーシップ理論に基づいています。 技術的課題 問題が明確で、解決策がすでに存在する 専門家が答えを持っている 既存の知識やス

Figure 1 無線LANの周波数と利用可能場所 ※図中では屋内利用の6GHz帯に○がありませんが、実際には利用可能です。 総務省　電波利用ポータル　無線LANの屋外利用／上空利用について　より抜粋 https://www.tele.soumu.go.jp/j/sys/others/wlan_outdoor/ Wi-Fi 6E/6GHz帯を利用するメリット では、Wi-Fi 6E/6GHz帯を利用するメリットはどこにあるのかをご紹介します。 1.ユーザーの少なさ 前述の通り2022年に利用開始されたWi-Fi 6E/6GHz帯ですが、対応するアクセスポイント（AP）、ルータ、クライアント端末利用ユーザ数は5GHz帯と比較してまだまだ少ない状態です。 例として、iPhoneシリーズでWi-Fi 6Eに最も早く対応したのは2023年9月発売のiPhone 15 Proであるように、市場に出回

はじめに 先日、dbt Cloudのローコード開発機能「dbt Canvas」（旧名称「dbt Visual Editor」）のGAを記念して、dbt Canvasを使ったモデルの作成や編集方法についての記事を投稿しました。 dbt Canvasは、GUIによる直感的な操作で、ローコードでモデルを作成・編集できる機能です。 dbt Canvasで作成したコードを後から手動で修正するケースを考えると、自動生成されるSQLを理解しておくことは非常に重要です。 本記事では、dbt の基本的な知識があり、dbt Canvasで生成されるSQLに関心がある方向けに、dbt Canvas上で利用できる「オペレーター」の操作によって、実際にどのようなSQLが生成されるのかを紹介します。 💡オペレーターとは？ データに対して行いたい操作（例：結合・フィルター）を、dbt Canvas上で設定するためのブ

はじめに 認証や認可の実現方法は、システム開発における頻出の関心事の一つかと思います。そんな中、JSON Web Token（JWT）／OAuth2.0／Open ID Connect（OIDC）という言葉もよく耳にするところです。 しかし、「JWTって結局どう使うの？」「OAuth2.0やOIDCってJWTとどう関係するの？」「OAuth2.0とOIDCの違いって何？」という疑問を持つ方も多いのではないでしょうか。 また、JWTに「署名」や「検証」といったキーワードが絡んでくると、途端にハードルが上がったように感じるものです。 これらのキーワードについては既に沢山の記事が公開されていますが、本記事では以下に焦点を当てて解説していこうと思います。 JWT／OAuth2.0／OIDCの関係性を明らかにする OAuth2.0／OIDCより先にJWTを理解することで混乱を防ぐ JWTをシステム開

はじめに 世の中には5Gなどのモバイル規格やTV放送、ETCなど電波を用いて無線で様々な情報を伝送する規格が存在します。一方、電波行政を管轄する総務省の電波利用ポータルによると、 「一方で、電波は大変デリケートなので、ルールを守らないと混信や妨害を起こしてしまいます。 電波の利用ルールをご理解いただき、クリーンな電波利用環境の維持にご協力下さい。」 との注意喚起が行われています。 そのため、各種無線規格には電波法及び関連法令により様々な制限が課されているため、我々は許された範囲内で電波を有効利用する必要があります。本シリーズでは、電波法で許された範囲内で電波を有効利用するため、各種無線規格をとことん使ってみた結果をご紹介いたします。 総務省　電波利用ポータル　電波の利用ルール　より https://www.tele.soumu.go.jp/j/adm/monitoring/summary/

はじめに はじめまして。NTTデータの奥村です。 最近は内部向けのちょっとしたドキュメントをMarkdown形式で記載することは結構あるのかなと思います。GitHubなどのリポジトリサービスやNotionなどのドキュメント共有サービスを全員が利用できればよいのですが、コストや組織のポリシーなどの関係でそうしたサービスが利用できないケースだと、関係者限定でMarkdownのファイルを見やすい形で共有するのに困ることがあります。 本記事では、上記のようなケースで役に立つ仕組みをAmazon Web Services (AWS)を利用して構築する方法を紹介させていただきます。 全体構成 まず、ドキュメント執筆者は何らかのリポジトリサービスにMarkdownファイルを配置します。次に、CI/CDサービスのCodePipelineがビルドサービスのCodeBuildを呼び出し、静的サイトジェネレータ

注目を集めるPostgreSQL＋Analytics 先日、SnowflakeとDatabricksのそれぞれの年次イベントでPostgreSQLに関連する企業の買収が大々的に発表されました。 両社は分析系（OLAP）のソリューションを提供する比較的大きなベンダーであり、過去にはOLTP系への進出を目指したデータストアの開発が注目されたこともありました（SnowflakeのUnistoreが典型です）。 彼らは今後、PostgreSQLを自社がカバーできていなかった領域で適用することで、現在のメガクラウドのようにOLTP用途のRDBとOLAPのソリューションを統合してくることが予想されます。 そして、多くの利用者を持つオープンソースのPostgreSQL（コミュニティ版と言っても良いかも知れません）においても、OLAPとの統合という流れは今後確実に訪れるというのが、私個人の予想です。 今回

はじめに 本連載記事「非機能要求グレードの歩き方」シリーズでは、 30年以上にわたり金融IT基盤に携わる中で得た経験と知識をもとに、 「やらかしがちな」技術的課題について、IPA[1]の非機能要求グレード[2]に沿って解説します。 （※筆者は非機能要求グレード初版の執筆に関わった経験があり、行間を含めて解説します。） 併せて「😱あったら怖い本当の話」として、実際に起きたことを、脱色デフォルメしたフィクションにして紹介します。 共通の注意事項（用語説明）

はじめに RSA暗号は、巨大な整数の素因数分解の困難性を安全性の根拠とする公開鍵暗号方式です。特にRSA-2048は、2048ビット長の合成数（10進数で約600桁）を利用しており、現代のスーパーコンピューターをもってしても、既存の素因数分解アルゴリズムでは現実的な時間内での分解は困難です。しかし、もし非常に大規模な量子コンピューターが実現すれば、従来のアルゴリズムと比較して飛躍的に高速な素因数分解アルゴリズムが実行可能になると予想されています。 では、RSA-2048を解読するためには、どの程度の規模の量子コンピューターが必要になるのでしょうか？ 2019年、GidneyとEkeråは、誤り率0.1%以下の2000万量子ビットを持つ量子コンピューターがあれば、RSA-2048を8時間で解読できるという推定を発表しました[1]。この件に関する日本語の解説は、以下の記事にまとめられています。

はじめに 本シリーズでは、Amazon Web Services (AWS) が提供しているAWS Well-Architected Frameworkのハイブリッドネットワーキングレンズを取り上げ、実際にどのような観点でチェックすべきか、そのポイントを前編と後編の2回にわたってご紹介します。本記事では、後編の信頼性、パフォーマンス効率、コスト最適化のチェックポイントについてご紹介します。 AWS Well-Architected Frameworkおよびハイブリッドネットワーキングレンズの概要については、前編の記事をご覧下さい。 本記事で得られるメリット ハイブリッドネットワーキングレンズは関連する追加のベストプラクティスが提供されていますが、「どのような時に何をすればよいか」が一目で分かりづらいことがあります。そこで、本記事はベストプラクティスをシンプルかつ明解なチェックポイントに要約

はじめに Amazon Web Services (AWS) が提供するAWS Well-Architected Frameworkは、AWSアーキテクチャを評価するためのベストプラクティスとして広く知られています。このフレームワークをベースとし、特定の業界やテクノロジー領域に特化した観点を提供するレンズがあることをご存じでしょうか。 本シリーズでは、ハイブリッドネットワーキングレンズを取り上げ、実際にどのような観点でチェックすべきか、そのポイントを前編と後編の2回にわたってご紹介します。本記事では、前編のオペレーショナルエクセレンス、セキュリティのチェックポイントについてご紹介します。 AWS Well-Architected Framework AWS Well-Architected Frameworkは、アーキテクチャを評価するためのベストプラクティスを提供しています。オペレーショ

近年話題のRAG（Retrieval-Augmented Generation）ですが、「社内資料」や「業務ドキュメント」としてよく使われる パワポ（PowerPoint）資料 に対しても応用できたら便利だと思いませんか？ この記事では、 「Cohere Embed 4」 + 「Gemini」 + 「FAISS」 を使って、 パワポ資料向けRAGシステム を構築する手順を紹介します。 初心者でも動かしやすいように、今回は一連のシステムをライトに構築・解説します。 はじめに：自己紹介 はじめまして。株式会社NTTデータグループ 技術革新統括本部 Innovation技術部の 割田 祥（わりた あきら） と申します。 業務では ローカルLLMのビジネス適用 を目指したFine-Tuning技術やアーキテクチャ設計などの研究開発を行っています。 今回は本業とは少し離れてはいますが、Cohereが

はじめに データエンジニアをやっておりますTaichiです。 最近Apache Icebergという単語をよく耳にするようになりました。 Icebergの処理エンジンといえば Apache Spark Apache Flink Trino などでしょうか。このラインナップ、構築/運用するのは結構ハードなものが多いと思いませんか？ 例えば、私のプロジェクトではSparkを使った構成でデータ処理を実施していますが、以下のような具体的な課題に直面しました。 Apache Hadoopのクラスタ構築作業や、Sparkを動かすために専用の記述（PySpark）が必要になる等、一定の学習が必要。 PySparkの記述の仕方によっては、性能が全然出ずにレスポンスが返ってこなかったり、OutOfMemoryになる場合があり、かつ解析やチューニングの難易度が高い。 クラウド前提であれば、マネージドHadoo

30年以上にわたり金融IT基盤に携わる中で得た経験と知識をもとに、「やらかしがちな」技術的課題について、IPA[1]の非機能要求グレード[2]に沿って解説します。 ※筆者は非機能要求グレード初版の執筆に関わった経験があり、行間を含めて解説します。 本記事では、オンライン性能要件における「B.1 業務処理量」に焦点を当てて解説します。 B.1 業務処理量の定義とオンライン性能要件 オンライン性能要件をまとめる際には、システムの性能目標値を決定する前に、その前提となる「業務処理量」を具体に定義することが重要です。 これは、1つの業務処理で発生する取引数は、インターフェース設計に依存して大幅に異なることがあるからです。 最初に着手するべきは、設計に依存しない業務処理量を明確にすることです。 下表は、非機能要求グレード 大項目「B:性能・拡張性」-中項目「B.1 業務処理量」のうち、オンライン性能

はじめに 昨今、欧州や日本を中心に発展しつつある「データスペース」について、皆さんに手を動かしながら体験頂けるようなブログを書いてみます。 本記事の想定読者 ITの基礎的素養はあるけど、データスペースのことをあまり知らない方 様々な分野でデータ利活用を検討している方 そもそもデータスペースとは データスペースとは、参加する組織・企業同士が互いに信頼できる仕組みのもとで、安全かつ自由にデータをやり取りできる制度と技術基盤が整った空間のことを指します。 こうした制度・技術の構築・標準化により、業界・組織・企業間のコラボレーションを加速し、横断的な課題解決や新たなデジタルサービスの創出を支えることができます。 データスペースは、近年欧州や日本を中心に広がりを見せています。以下の図はデータスペースの概念を表しています。データスペースの各参加者は、「コネクタ」と呼ばれるソフトウェアを用いて、「カタロ