トロルの姫 市原大志朗 【アフタヌーン四季賞2025春 四季大賞】感染症“白死病(パンドレ・シネ)”で人々が次々と死にゆく中、人里離れた場所でひとり死を待つナシャリアは、怪我を負った異形の者を見つけ手当てをする。彼が自身と同じく人間に厄災を振り撒く存在であると知ったナシャリアは、同じ境遇の仲間たちを解放すべく大きな決断をし、一世一代の闘いに身を投じる!!

本日、「AI駆動開発実践の手引き -これが僕/私のAI（アイ）棒」というイベントで「ここはMCPの夜明けまえ」 🎵🧭 というタイトルで登壇しました！ 🔍 イベント詳細: - イベント名: 【ハイブリッド開催】AI駆動開発実践の手引き -これが僕/私のAI（アイ）棒- - 公式URL: http…

RAGの限界性 RAG、つまり検索強化生成（Retrieval-Augmented Generation）は、現在の大規模言語モデル分野における注目の方向性です。これは情報検索技術と生成モデルを組み合わせ、大規模モデルの知識の正確性、文脈理解、最新情報の活用などの課題を解決します。 でも追加の知識をRAGを通じて導入するだけで、モデルがそれらの知識関連の質問に完璧に対応できると考えています。しかし実際と想像にはギャップがあり、実際に試してみると、RAGの精度はそれほど良くないことに気づくかもしれません。 RAG自体の技術的原理から見ると、現在以下の問題が存在します： 検索精度の不足：まず、RAGの最も核心的な部分は、知識を「ベクトル」に変換し、「ベクトルデータベース」に導入し、ユーザーの入力情報も「ベクトル」に変換してから、ベクトルデータベースから類似の「ベクトル」をマッチングさせ、最後に

VS CodeのCopilotとCopilot Chatを導入していてBusiness Planのシートを割り当てていただいているのですが、あまり活用できていなかったためどういった機能があるのか調査しました。 CopilotはGithub上で使えるCopilotやCLIから利用できるCopilotなどもありますが、ここではVS Code上から利用できるCopilotに焦点を当てています。 また拡張機能であるGitHub CopilotおよびCopilot Chatは事前にインストールされていることを前提としています。 Code completion これは使っているとすぐに気付ける、もうおなじみの機能といっても問題はず。 Control + Enter で他の候補も見ることができますが、自分はほとんど使ったことがありません。 また、Next Edit Suggestions(NES)という

粗悪品過ぎる激安ギターは弾き込んだら無改造でも『鳴る』ように変化するのか！？ギタいじ史上最も低品質なギターを無改造で3年間丁寧に弾き込みました！倍音や周波数特性、立ち上がりやサスティーンの変化を徹底調査しました！

本記事は、最近話題のMCPの入門記事です。 MCP（Model Context Protocol）について、以下の4ステップで紹介します。 ざっくり理解する 使ってみる 深く理解する 作ってみる 初心者でも順番に読み進めれば、MCPについてざっと理解、かんたんな実装ができるようになることを目指します💪 ざっくり理解する MCPとは、ざっくり言うと、LLMアプリと外部サービスを連携するための統一されたインターフェース(プロトコル)です。 LLMアプリとは、ChatGPTやClaude、Cursorなど、LLMを使用するためアプリケーションを指します。(⚠️ GPT-4oやclaude-3-5-sonnetなどのLLM自体とは区別してください。) 初期のLLMアプリは、どこまでいってもすごく賢いチャットツールでしかなく、結局はテキストを返答することしかできませんでした。 そのため、LLMアプ

はじめに この記事は GitHub Copilot の Tips を詰め込んだ記事になります。 GitHub Copilot を普段使っているが、コード補完しか使ってない方や、これから使おうと思っている方に向けて Tips をまとめて紹介する記事になります。 是非日々の開発ライフにお役立てください 🚀 GitHub Copilot とは？ GitHub Copilot は、開発者がコードをより速く、少ない労力で記述できるように支援する AI コーディング アシスタントです。 コンテキストに応じた支援を提供し、開発者が入力中にコードの提案を行います。 これは、行の補完の場合もあれば、まったく新しいコードのブロックの場合もあります。 これにより、開発者は問題解決、共同作業、イノベーションに集中できます。主要なエディターと統合され、GitHub にネイティブに組み込まれているこのツールは、最も

「あの人も読んでる」略して「も読」。さまざまな寄稿者が最近気になった情報や話題をシェアする企画です。他のテックな人たちがどんな情報を追っているのか、ちょっと覗いてみませんか？ みなさんこんにちは。 「あの人も読んでる」、第2回目の投稿です。maguro (X @yusuktan)がお届けします。 今回のテーマ: MCPAIの進歩があまりにも目覚ましすぎる昨今、いかがお過ごしでしょうか。僕は少しキャッチアップが遅れ気味で危機感を持っているところです。 そんな中で僕が最近導入して即座に「もっと早く使い始めておくべきだった」と感じたのが「MCP（Model Context Protocol）」です。 すでに利用している方も多いと思いますが、2週間前の筆者のように「MCPって最近よく聞くけど、まあいつか気が向いたら設定するか」と考えているような方がもしいらっしゃったら、そのような方の背中を押したい

他にもIPv4で個別に規定されたアドレス帯や、IPv6でも個別に規定されたアドレス帯がありますが本コラムでは省略します。 MACアドレスの考え方 MACアドレスは、ネットワークインターフェースを識別するために使用される識別子で、Ethernetでは48ビットで表現され、前半32bitがベンダーID、次の8bitが機器ID、最後の16bitがシリアルIDとなることが一般的ですが、例外もあります。過去にはすべての機器が一意に識別されるという説明もありましたが、現在ではこれも例外があります。ネットワークインターフェースごとにMACアドレスを持つため、複数のMACアドレスを持つ機器もあります。 同一ネットワークの通信の仕組み では、IPアドレスとMACアドレスを利用してどのように通信を行うかをおさらいしていきます。 同一ネットワークを192.168.0.0/24として送信元192.168.0.1と

PS部兼AT部の廣田です。 貴方がこの記事を読んでいる頃には、私はもう会社に居ないでしょう。（育休的な意味で） 最近、AWS Cognitoを使ってID管理を行っているシステムをよくみかけるようになりました。Cognitoは、面倒なログイン周りのアレコレを一手に引き受けてくれる便利なAWSのマネージドサービスです。パスワードの取り扱い、emailの到達確認、SMS、パスワードリセット、MFAデバイスの管理などなど……。これらをAWSがマネジメントしてくれるとなれば、独自実装するよりもそちらを使いたくなる人は多いのではないでしょうか。 ただ、実装を行わなくて良いかわりに、安全に利用するためには色々な設定が必要となります。もっともシンプルな Webアプリケーションでは自由にユーザ登録可能 Webアプリケーション側ではユーザの識別のためにJWTのsubクレーム（以降subと表記）のみを利用 とい

MCP概要説明 この記事はMCP2025-03-26リビジョンを基に作成しました。 Model Context Protocol (MCP) とは何か？ MCP は、AI アシスタント（チャットボットや自動化エージェントなど）が、さまざまな外部データやツールにアクセスするための 共通のルール（プロトコル） です。 従来は、AI にデータベースやウェブサービス、ローカルのファイルを使わせたいとき、それぞれ違う接続方法をいちいち作り込む必要がありました。すると、AI を拡張するたびに「新しいツール用の独自コード」を用意しなくてはなりません。 MCP を使うと、「AI ⇔ データやツール」 の接続方式を 標準化 できるため、同じ仕組みでいろいろなデータソースや外部サービスとやり取りできます。これは、AI の開発者とデータ管理者双方にとって、大きな手間削減や再利用性の向上につながります。 Anth

「日本の88x31バナー保管庫」は、個人サイト全盛期に多く見られた88x31ピクセルのバナーを収集・保存・公開するアーカイブサイトです。これらのバナーは、リンク集や相互リンクなどで使用され、当時のインターネット文化を象徴する存在でした。 ここで公開しているのは、主に1990年代後半から2000年代前半にかけて、日本国内のサイトで使用されていたバナーです。海外には国を問わず収集された88x31バナーのアーカイブも存在しますが、本サイトでは収集対象を日本国内に限定することで、日本独自のネット文化に焦点を当てています。 かつて個人サイトを運営していた方にとっては、「もしかして自分のバナーがあるかも？」という小さな発見も楽しんでいただけるかもしれません。 現在、88x31バナーはほとんど目にすることがなくなりましたが、その文化的価値を記録・保存することには大きな意義があると考えています。 この保管

4/9(水) お昼にYouTubeでも解説します🙌 やさしいMCP入門 ＆ 実践LT会（KAGと学ぼう！勉強会） https://kddi-agile.connpass.com/event/351600/

設置しているものだけでも19インチラックが2つ、NAS が4台 (うち1台は運用停止中)、ネットワーク機器は4台、汎用のノードが3台である。 実は画面外にデスクトップ PC が3台あり、ラックマウントでも設置していないネットワーク機器が2台と汎用ノードの芽 (CPU と M/B 抜き) が1台あるが、今回は関係ないのでさておこう。 薄々気付いてはいたが、一般のご家庭にしては些か数が多いようだ。 計算機リソースが多いというのは言ってみれば家が広いようなもので、「そんなに家が広くて何になるの」などと言う人はそういない。 リソースというのはあればあるだけ自由度が高まる便利なもので、その嬉しさを問うなど愚問である。 とはいえ、では具体的にその自由度を何に使っているかとなると、これは環境の差や個性の出るところであろう。 私のサーバ環境もゆったりと変化を続けている。 定点観測というわけでもないが、折角

Amazon Web Services ブログ Amazon Route 53 プロファイルで AWS PrivateLink の DNS 管理を効率化 本記事は 2025 年 2 月 18 日に公開された ”Streamline DNS management for AWS PrivateLink deployment with Amazon Route 53 Profiles” を翻訳したものです。 はじめに AWS PrivateLink インターフェイスエンドポイントを採用するエンタープライズ企業における主な課題は、導入プロセスの効率化、エンドポイント数の最小化、コストの最適化です。これらの課題に対処するための実績あるアプローチは、AWS Transit Gateway と Amazon Route 53 Resolver を組み合わせて使用し、複数の Amazon Virtual