0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Qiitaのトレンド記事を要約してまとめたもの(サボり)

Posted at

プロンプト・エンジニアリングは、まだ始まってすらいない

AI, プロンプト, ChatGPT, LLM, プロンプトエンジニアリング

  • 201 Likes, 165 Stocks, 0 Comments
  • POSTED @ 2025/11/16___UPDATED @ 2025/11/16
  • Author : @makotosaekit

プロンプト・エンジニアリングは、AI性能向上に伴い、小手先の技術から体系的なコンテクスト・エンジニアリング、AIの思考プロセス設計であるコグニティブ・プロンプティングへと進化している。

Googleの資料は、テクニックの一般教養化を宣言し、ReActなどのフレームワークの本質的な理解の重要性を示唆。役割設定では、思考プロセスを持つ専門職の指定が有効で、アイデンティティに関わる役割は避けるべき。

コンテクスト・エンジニアリングは、AIとの対話を情報環境の設計と捉え直し、コンテキストウィンドウの増大とRAGの一般化が背景にある。7つの道具(前提、状況、目的、動機、制約、形式、参照)でAIの思考をガイドし、RAGによる情報提供とプロンプトによる思考フレームワークの提供を組み合わせる。

コグニティブ・プロンプティングでは、人間の思考プロセスをAIにインストールし、メタ認知プロンプティングでAIに自己反省を促す。体系的フレームワークでプロンプトを構造化する。ただし、認知バイアスの注入には注意が必要。

対話の設計者として、最終責任は常に人間にあり、ハルシネーションを前提に検証可能な事実を扱い、手法より原理と文脈の一貫性を追求することが基本原則。思考を設計する力が重要になる。


【libxml2】libxml2プロジェクトは放棄されました

Security, libxml2, 脆弱性, OSS, 協調的脆弱性開示プロセス

  • 51 Likes, 18 Stocks, 0 Comments
  • POSTED @ 2025/11/17___UPDATED @ 2025/11/18
  • Author : @rana_kualu

libxml2はXML処理ライブラリで、多くのLinuxディストリビューション、プログラミング言語、Webブラウザで使用されている事実上の業界標準。PHPのDOMやSimpleXMLも依存。

長年Daniel Veillardが開発し、現在はNick Wellnhoferがほぼ一人で保守。

セキュリティバグ報告は通常、修正まで非公開だが、libxml2はセキュリティバグも全て公開する方針に転換。

背景にはOSS開発者の稼ぎが少ない問題があり、Nick Wellnhoferは資金不足からメンテナを一時辞任、Googleの寄付で復帰するも、第三者からのセキュリティ問題対応に時間を取られ、無償ボランティアでは持続不可能と判断。

OpenSSFのような組織は高額な会費を要求するだけで、OSS開発者への貢献還元はないと批判。

Google Project Zeroも脆弱性指摘のみでパッチ作成をしないと批判されている。

Nick Wellnhoferはlibxml2のメンテナを辞任し、プロジェクトはほぼメンテナンスされていない状態。

Appleは独自改造版を公開しているが、他プラットフォームでの動作は不明。


【React】コードを書く前の基本概念を理解する

JavaScript, 初心者, 初心者向け, React, 初心者エンジニア

  • 85 Likes, 98 Stocks, 0 Comments
  • POSTED @ 2025/11/16___UPDATED @ 2025/11/16
  • Author : @ktdatascience

ReactはUI構築のためのJavaScriptライブラリで、コンポーネントを組み合わせてUIを作成します。コンポーネントは見た目と機能を一体化し、JSXでHTMLのような構文を記述します。JSXはBabelによりJavaScriptに変換されます。Appコンポーネントを起点に階層構造を作り、インポート/エクスポートでコンポーネントを分割管理します。ファイル名とコンポーネント名は一致させ、CSSや画像もインポート可能です。これらの基本を理解し、実際にコードを書いてReactに慣れましょう。


【TOON】JSON時代の終わり? 話題のTOONを解説してみた

JSON, AI, Toon, LLM, AIエージェント

  • 41 Likes, 21 Stocks, 0 Comments
  • POSTED @ 2025/11/17___UPDATED @ 2025/11/17
  • Author : @shanks665

LLMのAPIコスト削減に有効なデータ形式「TOON」を紹介。JSONに比べ30〜60%トークンを削減可能。
JSONは冗長な記号が多いが、TOONはフィールド名を一度だけ宣言し、値のみを並べるため効率的。
利点:コスト削減、レスポンス高速化、コンテキスト活用、推論・検索精度向上。
JSONとの互換性があり、段階的な導入が可能。
公式SDKが複数言語で提供。
大量の表形式データを扱う場合に特に有効。
複雑なネスト構造やLLMの学習データ不足には注意。
LLMとの境界でのみTOONを使用し、効果測定しながら段階的に導入するのが推奨。


文字をうつということ|キーボード・オタク(著)

Keyboard, キーボード配列

  • 15 Likes, 1 Stocks, 0 Comments
  • POSTED @ 2025/11/17___UPDATED @ 2025/11/17
  • Author : @kanekanekaneko

この記事は、タイピング技術向上のため、安易なTipsではなくキーボードと文字入力へのこだわりを提唱。

  • ノートPC付属や会社貸与のキーボードに満足せず、理想のキーボード、文字入力を追求すべき。
  • 物理配列(サイズ、レイアウト)、論理配列、キースイッチ、椅子が重要。

物理配列

  • サイズ: できるだけ小さいサイズ推奨(40〜50%)。
  • レイアウト: ロウスタッガード以外、分割キーボード推奨。
  • 正規販売店での購入や自作キーボードを検討。

論理配列

  • Qwerty配列からの脱却。
  • 英語配列: Dvorak, Colemak, Minimak。
  • 日本語配列: Eucalyn, 大西配列, 金子配列(自作), 薙刀式, NICOLA, 漢字直接入力, 速記, SKK。
  • 自作推奨。

キースイッチ、キーキャップ

  • 基本的に交換不要。

椅子

  • アームレストが机と同じ高さまで伸びるものを。

HTTPS通信とTLSの仕組みを理解する

Security, SSL, HTTPS, TLS, Let’sEncrypt

  • 14 Likes, 8 Stocks, 0 Comments
  • POSTED @ 2025/11/18___UPDATED @ 2025/11/18
  • Author : @kazuki_ogawa

HTTPSはHTTP+TLSで構成され、TLSで暗号化し盗聴や改ざんを防ぐ。SSLは旧規格で現在はTLS1.2/1.3が主流。
鍵交換はECDHE方式で秘密の値を送らずに共通鍵を共有。共通鍵はG×A×Bのように数学的に一致。公開値から秘密値を逆算は困難。
共通鍵確立後、共通鍵暗号(AES等)で高速に通信を暗号化。
Let's Encryptは無料の認証局として証明書を発行し、ドメイン所有を確認しサイトの正当性を保証。ブラウザはCA署名を検証し証明書を信頼。証明書にはドメイン名、公開鍵、有効期限、発行者、署名が含まれる。Let's EncryptはHTTP-01、DNS-01などのチャレンジでドメイン所有を認証。証明書はルートCA、中間CAを経てサーバー証明書へと信頼が連鎖する。HTTPSは数学と暗号技術で安全性を担保。


家族会議が「感情論」で炎上するので、心理的安全性を守るアプリをAIと二人三脚で作った話

AI, Firebase, ファシリテーション, Flutter, OpenAI

  • 7 Likes, 2 Stocks, 0 Comments
  • POSTED @ 2025/11/17___UPDATED @ 2025/11/18
  • Author : @a-nagaoka

家族会議がうまくいかない理由として、責められていると感じやすいことや遠慮のなさがあげられる。
これを解消するため、家族会議サポートアプリ「fameet」を開発。
fameetは、AIでアジェンダを作成し、猫のようなキャラクター「みーとん」が話し合いをサポート、決定事項を記録する。
技術要素はFlutter、drift(SQLite)、OpenAI API、Firebase Functionsなどを利用。
開発ではCline(Claude)、ChatGPT、Geminiなどの生成AIを活用したが、ライブラリ選定やコードのコメントの重要性を学んだ。
fameetで家族会議が平和になることを願っている。


Windowsでずっと開発してた人がMacで働くためのTips

Zsh, Mac, GitHub, homebrew, warp

  • 9 Likes, 4 Stocks, 3 Comments
  • POSTED @ 2025/11/15___UPDATED @ 2025/11/16
  • Author : @suecideTech

WindowsからMacbookに移行した開発者向け、操作性向上のためのツールと設定。

  • altTab: Windows同様のAlt+Tabによるウィンドウ切り替えを実現。
  • Smooze Pro: マウス加速OFF、スムーズなスクロール、ボタンへの機能割り当て(Mission Control推奨)。
  • Dock設定: 位置を左、サイズ縮小、自動非表示、展開速度高速化。Spotlightでのアプリ起動がメイン。

その他開発環境セットアップ:

  • Homebrew: パッケージ管理。
  • Ark: ブラウザ (Cmd+Eでサイドバー非表示)。
  • Warp: ターミナルエミュレーター (入力補完が強力)。
  • GitHub Desktop + gh コマンド: リポジトリClone、PRブランチ切り替え。
  • Cursor/Claude Code: AIコーディング支援。
  • VS Code: フォントHackGen、各種設定(settings.json)、キーバインド設定(keybindings.json)。

自分に合った開発環境は作業効率と楽しさを向上させる。


初めて技術書典にサークル参加したら、楽しすぎた件

ポエム, #技術書典

  • 39 Likes, 6 Stocks, 0 Comments
  • POSTED @ 2025/11/16___UPDATED @ 2025/11/16
  • Author : @MIDO-ruby7

技術書典オフライン参加が最高に楽しかった。サークル参加の条件は、自走力、本の完成、朝9:30までに会場到着、夕方17:00まで諦めない心、宣伝力。改善点として、本のテーマを明確に、見本誌なしでも内容が分かる工夫、早割の確認。後から印刷はページ数制限あり。部数調査は当てにならない場合も。その他、会場内飲食可能、荷物は増える。技術書典はエンジニアなら誰でも参加可能、好きなものを書くのが同人誌。


僕のClaude Code Plugin紹介 ~skills/create-git-worktree~

AI, Claude, AIエージェント, ClaudeCode, AgentSkills

  • 7 Likes, 2 Stocks, 0 Comments
  • POSTED @ 2025/11/17___UPDATED @ 2025/11/17
  • Author : @getty104

Claude CodeのPlugin機能で自身の環境を公開しており、今回は実装したSkillを紹介。SkillsはClaude Codeがタスク実行時に参照する再利用可能な知識・手順で、Markdownファイルとして定義。紹介するSkillはgitのworktreeを作成するもので、worktreeの作成、移動、必要なファイルのコピー、ライブラリのインストールなどを自動化。プロンプトとスクリプトはGitHubで公開。Skillsを使うことで、スクリプト実行やワークフロー実行を自動化できる。


KiroとAmazon Q Developerの比較(2025/11/18)

AWS, qdeveloper, Kiro

  • 5 Likes, 1 Stocks, 0 Comments
  • POSTED @ 2025/11/18___UPDATED @ 2025/11/18
  • Author : @moritalous

Amazon Q DeveloperがKiroとしてGA。Kiro CLIが利用可能。料金プランはFree, Individual, Enterpriseの3種類。ログイン方法はGitHub, Google, AWS Builder ID, AWS IAM Identity Center。Kiro IDEは全プランで利用可能。Amazon Q IDEプラグインとJava変換機能はKiroでは利用不可。管理者機能はEnterpriseのみ。データ利用に関する設定がプランごとに異なる。マネコンでのQは全プランでQ Dev Free相当、Q Dev ProのみQ Dev Pro。


中学生がAndroidアプリ開発してGooglePlayで公開した話

Android, GooglePlay, 中学生, Flutter

  • 8 Likes, 3 Stocks, 0 Comments
  • POSTED @ 2025/11/16___UPDATED @ 2025/11/16
  • Author : @nekogakure

中2のねこがくれがFlutterでAndroidアプリ「ココロノート」を開発・リリース。
C/Rust経験はあるが、大衆的なものを作るためGooglePlayでのアプリ公開に挑戦。
Dartを学習後、5日で仮実装。
未成年ゆえ親にGoogleDeveloper登録の許可を得る必要があり、完成したアプリを見せて説得。
クローズドテストでテスター確保に苦労し、貢献内容を具体的に示さずリジェクトされるも、改善点を指摘してもらい再申請で製品版をリリース。


豆腐文字(□□□)を解消!ChatGPTで日本語が崩れないグラフを作る方法

日本語, 文字化け, グラフ, ChatGPT, GPTs

  • 5 Likes, 1 Stocks, 1 Comments
  • POSTED @ 2025/11/17___UPDATED @ 2025/11/18
  • Author : @rrwatanabe

ChatGPTでグラフ作成時に日本語が文字化けする場合、原因は実行環境に日本語フォントがないこと。解決策は、Noto Sans JPなどの日本語フォント(TTFファイル)をChatGPTにアップロードし、利用を指示すること。

手順:

  1. 日本語フォントをダウンロード(例:Noto Sans JP)。
  2. ChatGPTにフォントファイルをアップロード。
  3. データと共に「このフォントを使う」と指示。

頻繁に使う場合は、カスタムGPTにフォントを登録すると便利(有料プラン)。


日刊IETF (2025-11-17)

TLS, QUIC, pqc, 日刊IETF, ML-KEM

  • 5 Likes, 2 Stocks, 0 Comments
  • POSTED @ 2025/11/18___UPDATED @ 2025/11/18
  • Author : @tetsuko_room

2025-11-17のIETF関連情報:Internet-Draft12件、RFC0件。
PQC移行を見据えた技術仕様(TLS 1.3のハイブリッド鍵交換、ML-KEMのセキュリティ考慮事項)、QUIC拡張(Media over QUICリレーのベンチマーク、低ACK頻度RTT推定)、OAuth認証管理URI追加、OpenID ConnectクレームのCBOR対応などが公開。
PQC時代の実装準備本格化。ML-KEMとECDHEの組み合わせで量子コンピュータの脅威に備えつつ現行システムとの互換性を維持。QUICベースのリアルタイムメディア伝送やMPEG-I触覚データのRTP伝送など、次世代通信プロトコルにおける新たなユースケース対応も進む。


【LTS】.NET 10 × Visual Studio 2026 で始める Azure Functions 開発 - C# 14 の新機能も紹介

C#, Azure, .NET, VisualStudio, AzureFunctions

  • 10 Likes, 9 Stocks, 0 Comments
  • POSTED @ 2025/11/15___UPDATED @ 2025/11/17
  • Author : @s_w_high

.NET 10とVisual Studio 2026を使用してAzure Functionsアプリケーションを作成する方法を解説。
.NET 10はLTSバージョンで2028年11月までサポート。
Visual Studio 2026のインストールと.NET 10 SDKのインストール手順を説明。
.NET 10のランタイムとC# 14の新機能(field-backed properties等)を紹介。
Visual Studio 2026の新機能としてGitHub Copilotの統合、デバッグの改善、Markdownプレビューの強化を説明。
Azure Functionsプロジェクトの作成手順、ローカルでの実行確認、Azureへのデプロイ方法を記載。
分離ワーカーモデルへの移行が推奨され、インプロセスモデルは2026年11月10日にサポート終了。
C# 14の新機能をAzure Functionsで試す例を紹介。
参考文献として.NET 10のサポートポリシー、Visual Studio 2026リリースノート、Azure Functionsのドキュメント等を掲載。


意外と使ってない?SlackのRSS通知設定で最新情報をキャッチアップ!

tips, RSS, Slack, 情報収集, 業務効率化

  • 16 Likes, 1 Stocks, 0 Comments
  • POSTED @ 2025/11/17___UPDATED @ 2025/11/17
  • Author : @imamu123

SlackでRSSフィードの更新通知を受け取る方法

  1. RSSフィードのURLを取得
  2. SlackでRSSアプリを追加し、フィードURLと通知チャンネルを設定
    注意点:
  • メンションは指定不可。チャンネルの通知設定変更で対応
  • 通知はリアルタイムではない
    活用例:
  • Qiitaの記事更新
  • AWS、Azure、GoogleCloudの障害通知

【徹底調査】暗号利用の視点からXの「Chat」ってどんなサービス?

Security, chat, X, メッセージング

  • 4 Likes, 2 Stocks, 0 Comments
  • POSTED @ 2025/11/18___UPDATED @ 2025/11/18
  • Author : @satokan3

X(旧Twitter)が新メッセージング機能「Chat」をローンチ。
技術仕様書は未公開。
MLSは不採用で、Bitcoin-style暗号化(secp256k1等の静的楕円曲線暗号)を採用か。
PFS欠如の可能性があり、鍵漏洩で過去ログが復号されるリスクがある。
PQC非対応。
秘密鍵はサーバー管理(PIN保護)。
MLSのような動的な鍵更新はなし。
Perfect Forward Secrecy(PFS)が欠如している可能性。
MITM対策が不明確。
量子コンピュータへの耐性がない。
技術仕様書が非公開で第三者検証が困難。
PFSが必須な場合や、国家レベルの監視を回避したい場合は利用を推奨できない。
透明性、プロトコル、鍵管理、Forward Secrecy、PQC対応を見極める必要あり。


【徹底解剖】ChatGPTグループチャットのセキュリティ アレコレ(後編)

Security, chat, 暗号化, ChatGPT

  • 6 Likes, 2 Stocks, 0 Comments
  • POSTED @ 2025/11/17___UPDATED @ 2025/11/17
  • Author : @satokan3

ChatGPTグループチャットのセキュリティ(後編):技術的詳細

通信はTLS 1.2以上で暗号化。鍵交換にECDHE、共通鍵暗号にAES-GCM/ChaCha20-Poly1305、署名にRSA-PSS/ECDSAを想定。TLS終端後の平文はモデル推論、監査ログ、コンプライアンスチェックに使用。

保存時はAES-256で暗号化。Envelope Encryptionを採用し、DEKでデータを暗号化、KEKでDEKを暗号化。KEKはKMS/HSMで保護。鍵ローテーション、アクセス制御、パフォーマンス効率化が利点。

鍵管理は通常プランではOpenAI管理、EnterpriseではEKM(BYOK)が利用可能。EKMは顧客が鍵を管理し、アクセス制御・監査が可能。ただしE2E暗号化ではない。

他サービスとの比較では、ChatGPTはサーバ集中型。Signal等はE2E型。PQC移行は2025年から始まり、2029-2030年に業界標準になる見込み。OpenAIにはTLS 1.3必須化、PQC導入、EKM拡張が期待される。

ChatGPTはエンタープライズ向けクラウドコラボレーションツールのセキュリティ標準に準拠。SOC 2 Type II、GDPR準拠。導入時はアーキテクチャ理解、鍵管理戦略、PQC対応計画が重要。E2E必須の用途には別ツールを検討。


Next.js / React.js向けFeature-Driven Architecture: AIに優しく、保守可能でスケーラブルなコード整理

AI, React, Next.js

  • 9 Likes, 6 Stocks, 0 Comments
  • POSTED @ 2025/11/17___UPDATED @ 2025/11/17
  • Author : @TOMOSIA-HieuNT

この記事では、Next.js/React.jsアプリケーション向けのFeature-Driven Architectureを紹介。コードの明確な整理、AIとの連携、スケーラビリティ、容易なオンボーディングを目的として設計。

プロジェクトの背景として、80画面以上、800ファイル以上の規模で、チームメンバーが頻繁に変わるアウトソーシングシステムでの技術的負債を解決するために採用。

技術スタックはNext.js、React、TypeScript、Tailwind CSSなどで構成。

問題点として、開発者間のコードの一貫性の欠如、巨大なコンポーネント、オンボーディングの困難、依存関係の混乱などを指摘。

Feature-Based Patternの利点として、明確な分離、並行開発、オンボーディングの容易さ、スケーラビリティ、AIとの親和性を挙げる。

詳細なアーキテクチャでは、appディレクトリ(ルーティング)、featuresディレクトリ(機能)、componentsディレクトリ(共有UI)、sharedディレクトリ(グローバルユーティリティ)の構造を解説。

黄金の原則として、各機能=1ページ、インポート階層、パブリックAPIパターン、機能間の直接インポート禁止、UIとロジックの分離、必須の機能構造を強調。

AIに優しいベストプラクティスとして、命名規則、型定義、ファイル構造、パブリックAPIパターン、コメント、一貫したパターン、インポートパス、AI向けプロンプト、コード組織、テストの重要性を解説。

レスポンシブデザイン、テスト戦略についても言及。

適用後の結果として、オンボーディング時間、バグ修正時間、コードレビュー時間、開発者の満足度の改善を示す。

欠点とトレードオフとして、小規模プロジェクトへの過剰設計、sharedかどうかの決定に時間がかかる、フォルダの深さ、高い規律の必要性を指摘。

新機能実装時のチェックリストを提供し、結論として、Feature-Based Architectureは大規模なNextJSプロジェクトのコード整理に効果的であり、原則の遵守、一貫性、コードレビュー、ドキュメントの重要性を強調。


OWASP BWAで学ぶ、脆弱性検証体験

Security, OWASP_ZAP, owasp, OWASP_BWA

  • 3 Likes, 5 Stocks, 0 Comments
  • POSTED @ 2025/11/17___UPDATED @ 2025/11/17
  • Author : @Inlet-back

脆弱性診断のフローをOWASP BWAで体験。ツール(OWASP ZAP等)で自動検証後、手動で脆弱性の有無を検証する。

検証環境: M2 MacBook Air, UTM, OWASP BWA/Kali Linux仮想マシン, Firefox, Burp Suite, OWASP ZAP。

準備: OWASP BWAとKali Linuxを起動し、IPアドレスを確認。Kali LinuxのFirefoxでOWASP BWAにアクセス。OWASP ZAPの証明書をFirefoxにインポート。

手順:

  1. 偵察: アプリ(peruggia)の概要を把握し、攻撃対象となりそうな箇所を洗い出す(ログインページ, About編集, Paper詳細, コメント)。
  2. 自動スキャン: ZAPでperuggiaをActive Scan。Technologyタブでスキャン対象技術を絞り込み(Ubuntu, Apache, PHP, Python, Perl)。Spiderで網羅的な検査。
  3. 発見と評価: ZAPのアラート(クロスサイトスクリプティング)を確認。URL、リスク、ペイロード、脆弱性の説明を確認。
  4. 手動検証: ZAPが見つけたペイロードを手動で確認。Paper詳細画面のXSSは再現。コメント欄のXSSは不発。
  5. ツールでの箇所を手動で詳しく: コメント欄のXSSを検証。onMouseOverイベントハンドラでの構文エラーを修正(コメントアウト)。onMouseOver=alert(1);//でアラート表示成功。

まとめ: ツールと手動検証を組み合わせることで、より正確な脆弱性検証が可能。

今後:

  • 他の脆弱性の検証
  • 未検出の脆弱性(ネガティブフォールス)の検証
  • 検証した脆弱性のトリアージ
  • 脆弱性レポートの作成

Copilot Studio でエージェントフローにファイルを渡す

PowerAutomate, copilot, CopilotStudio

  • 8 Likes, 5 Stocks, 0 Comments
  • POSTED @ 2025/11/15___UPDATED @ 2025/11/16
  • Author : @Takashi_Masumori

Copilot Studioでチャットからファイルを受け取りAIプロンプトに渡す際、ファイルから直接情報を抽出できない場合がある。その代替案として、AIモデルのOCRを使って抽出したテキストをプロンプトに渡す方法を紹介。エージェントフロー側でファイルを受け取りOCR処理し、エージェント側トピックで質問ノードを介してファイルを受け取り、特定形式でエージェントフローに渡す。この方法で、Copilot Studioからエージェントフローにファイルを渡し、OCR結果を取得できる。


PADでメール配信ロボット作ったら「3分のはずが…1時間20分」になった話

Excel, RPA, 業務自動化, PAD, PowerAutomate

  • 3 Likes, 1 Stocks, 0 Comments
  • POSTED @ 2025/11/17___UPDATED @ 2025/11/18
  • Author : @sugasawakazumi

Power Automate Desktop (PAD)でExcelデータから条件抽出してメールを自動作成するロボットを開発。
テストでは100行3分で完了したが、本番の8000行では1時間20分かかった。
原因はPADが「大量データ×文字列結合×条件分岐」が苦手なこと。
特に会社名を結合してメール本文を生成する処理が重く、行数が増えると処理時間が大幅に増加。
Excelの行ループ処理、HTMLメールの整形、添付ファイルのパス指定なども負荷になった。
データ量が多い場合のPADの性能問題が明らかになった事例。
この経験から自動化すべきポイントを再考し、別のアプローチを検討中。


【イベントレポート】生成AIと共に、長期運用プロダクトのさらなる成長を加速させるための実践知

レガシーシステム, イベントレポート, 生成AI, 長期運用プロダクト

  • 3 Likes, 0 Stocks, 0 Comments
  • POSTED @ 2025/11/5___UPDATED @ 2025/11/18
  • Author : @clipnote

コドモン、ウエディングパーク、クイックの3社共催で「生成AIと共に、長期運用プロダクトのさらなる成長を加速させるための実践知」イベントを開催。長期運用プロダクトにおける生成AIの活用事例を共有し、情報交換や学びを深めた。

LT発表では、AI爆速開発の副作用と対策、コンテキスト管理の重要性、生成AI導入の壁と乗り越え方、技術的負債の返済におけるAIの可能性、GitHub Copilotの活用事例、リプレイスPJでのAIコーディング導入による効率化などが共有された。

パネルトークでは、AI活用文化の醸成や長期運用プロダクトならではの失敗談などが議論された。

懇親会では、生成AIの活用事例について活発な情報交換が行われた。

イベント全体を通して、生成AIをツールではなく仲間として捉え、文脈を理解させて依頼することの重要性が強調された。


【解説記事】ML-KEM Security Considerations が気になったので読んでみた

暗号, ietf, pqc, cfrg, ML-KEM

  • 3 Likes, 2 Stocks, 0 Comments
  • POSTED @ 2025/11/18___UPDATED @ 2025/11/18
  • Author : @satokan3

GMOコネクトCTO菅野氏による、IETFで紹介されたML-KEM Security Considerationsの解説記事。PQC移行に伴い、NISTがML-KEMを標準化したが、実際のプロトコルでの安全な利用ガイドラインが不足していたため、主要ベンダとNISTが協力して公式運用ガイドを作成。

このDraftは、ML-KEMを安全に使うための横断的なガイドラインで、プロトコルレベルでの運用上の注意点を体系的にまとめている。

主要な推奨事項は、高品質な乱数生成、認証の必須実装、鍵ライフサイクルの明確化、上位プロトコルの活用。HPKEの利用を推奨。Decapsulation failureや非定数時間実装は無視してよい問題だが、Misbinding攻撃には注意が必要。

このDraftは他のプロトコルからも参照される予定で、実装の落とし穴回避、標準化された運用知識、プロトコル設計の効率化、セキュリティレビューの基準となる。ML-KEMを安全に利用するためのRNG要件、鍵管理、認証設計などが詳細に解説されている。


【徹底解剖】ChatGPTグループチャットのセキュリティ アレコレ(前編)

Security, chat, 暗号化, ChatGPT

  • 12 Likes, 4 Stocks, 0 Comments
  • POSTED @ 2025/11/17___UPDATED @ 2025/11/17
  • Author : @satokan3

ChatGPTのグループチャット機能のセキュリティ評価。OpenAI公式ドキュメントに基づき、暗号化、保存、鍵管理の実態を調査。TLS 1.2以上での通信暗号化、AES-256での保存時暗号化、サーバサイドKMSによる鍵管理が行われているが、E2E暗号化、MLS、PQCには対応していない。Slack/Teamsと同クラスのクラウドチャットとして扱うのが妥当。機密度に応じた利用判断、社内ポリシー策定、PQC対応状況の監視を推奨。長期秘匿性が必要な情報は別チャネルで管理。


新人エンジニアが「文章づくり」でAIを相棒にするときの自分ルール

AI, 新人エンジニア, ChatGPT

  • 8 Likes, 2 Stocks, 0 Comments
  • POSTED @ 2025/11/17___UPDATED @ 2025/11/17
  • Author : @kmatsuda_slj

エンジニア1年目がAIを文章作成サポートに使う際のルール:まず自分の言葉で下書き、メモはぼかして利用、メール等はトーンと構成のみをAIに依頼、最終確認は必ず自分で行う。AIを「文章づくりの相棒」として活用し、効率化を図りつつも内容と責任は自身で持つ。


エンジニアの脳が壊れる瞬間 ─ 複雑性・認知負荷・計算量のメカニズム

設計, アーキテクチャ, エンジニア, 認知負荷, 複雑性

  • 2 Likes, 2 Stocks, 0 Comments
  • POSTED @ 2025/11/18___UPDATED @ 2025/11/18
  • Author : @Sakai_path

ソフトウェアの複雑性は計算量の爆発として現れ、人間の認知限界を超えることで破綻する。人間の作業記憶には限界があり、設計の計算量がそれを超えると理解が困難になる。複雑さはコード量ではなく関係性の数で決まり、関係性が増えるほど理解コストは指数関数的に増加する。認知負荷は技術負債として蓄積し、理解困難さ、仕様とコードの不一致、影響範囲の不明確さなどを引き起こす。アーキテクチャの本質は計算量の制御であり、層の分離、責務の限定、境界の作成、API設計などを通じて認知負荷を最小化する。複雑性の破綻ラインはチームの認知能力に依存し、チームの最低ラインで設計する必要がある。実務では、関係性を減らし、読みやすさを向上させ、ドキュメントではなく構造で説明し、レビューで認知負荷を観測し、チームの認知限界を把握することが重要。ソフトウェアの限界は人間の認知資源で決まるため、複雑性と共存できる形を探すべきである。


disposable-lock v2 で チェックボックスをロックするサンプル

JavaScript, TypeScript, WebLocksAPI

  • 2 Likes, 1 Stocks, 0 Comments
  • POSTED @ 2025/11/17___UPDATED @ 2025/11/17
  • Author : @juner

disposable-lock v2系の改善を体験できるチェックボックスグリッドのサンプル。

  • チェックボックスクリックで空いているロックを取得、失敗で操作スキップ
  • チェック解除でロック解放
  • 色でロック状況を可視化
  • ifAvailable: trueでロック取得失敗時にnullを返し安全
  • data-lock属性とCSSでリソース占有状況を表示

Windows環境でRust+OpenCVを動かす

Rust, OpenCV

  • 2 Likes, 1 Stocks, 0 Comments
  • POSTED @ 2025/11/18___UPDATED @ 2025/11/18
  • Author : @Tsuyopon-1067

WindowsでRustとOpenCVの環境構築手順:

  1. RustとChocolateyをインストール。
  2. cargo new cvtestでプロジェクト作成し、cargo add opencvでOpenCVクレートを追加。
  3. ChocolateyでLLVMとOpenCVをインストール (choco install llvm opencv)。
  4. 環境変数OPENCV_LINK_LIBSOPENCV_LINK_PATHSOPENCV_INCLUDE_PATHSを設定(OpenCVのバージョンに注意)。
  5. LLVMのパスを環境変数PATHに追加。
  6. Windows形式でOpenCVのDLLファイルがあるディレクトリを環境変数PATHに追加。

Code-Driven データ分析ナイト #2 セマンティックレイヤー

Databricks, Snowflake, dbt

  • 2 Likes, 0 Stocks, 0 Comments
  • POSTED @ 2025/11/18___UPDATED @ 2025/11/18
  • Author : @manabian

Code-Driven データ分析ナイト #2 で発表した「データ利活用におけるセマンティックレイヤー概要」をまとめた記事。

セマンティックレイヤーは、ビジネス用語を用いたデータ表現であり、理解と活用を容易にするもの。

データマネジメント業界では Knowledge Graph によるセマンティックレイヤーが注目されている。

dbt Platform, Snowflake Semantic Layer, Databricks Metric View での実装コードはGitHubで公開。

Knowledge Graph については Graphwise 社の資料が参考になる。

Databricks と Snowflake の TPC-H データを用いたサンプルコードあり。データ利活用におけるセマンティックレイヤー実装にはディメンションモデル(スタースキーマ、スノーフレークスキーマ)を利用。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?