Presentation slides for Azure OpenAI Service Dev Day 2025 Session title: AI Ready API ─ AI時代に…
Microsoft Copilot Studio でカスタムのエージェントを最近作り始めた方は、システムとの連携にMCPを利用したり、APIも利用することもあると思います。ありがちな勘違いが、APIをそのままMCPにすればいいじゃないか?という考えを持つこともありますが、MCPの本質を理解し、何が違うのかを理解することで、より良いエージェントを作れるようになります。そこで今回はMCPとAPIの違いについて、触れたいと思います。 MCP ってそもそも何? MCP(Model Context Protocol)は、Anthropic が 2024 年末に公開したオープンプロトコルです。狙いは、大規模言語モデル(LLM)が外部サービスをもっと自然に扱えるようにすることです。 基本的には 3 つの要素があります。 ツール― LLM が実行できる“アクション”。 リソース― ツールが扱う対象物や I
過去2回の記事でREST API 設計指針をまとめてきました。 REST API 設計指針・認証認可編 REST API 設計指針・通信、パラメーター編 今日は第三回かつ最終回のセキュリティ編です。セキュリティは非常に幅広い概念であり、考慮すべきことは山盛りですが、まずは基本的な考え方から。 加害者と被害者の逆転現象 悪意のある第三者からの攻撃などにより何某かのインシデントが発生して、サービスが停止したり、情報漏洩が起きてしまった場合、サービス事業者はステークホルダーにお詫び、時には直接的な金額による賠償を行うことになります。本来システムを攻撃された被害者側ですが、加害者であるかのような扱いをされるケースがあります。一方インシデントの種別によっては世の中が同情的になるケースもあります。この違いについてですが、一般的によく用いられる対策をとっていたかどうかが大きな分岐点となります。 攻撃され
TL;DR 医療情報規格は背景技術に併せて進化してきました。代表的な医療情報標準規格の一つであるHL7規格はその誕生から今に至るまで背景技術の影響を色濃く受けています。FHIRは、現在の主流技術の一つであるRESTを活用した最新のHL7規格であり、医療DX時代の標準規格として広く普及しつつあります。 1. はじめに 医療DX入門講座6で医療情報標準規格について解説しました。医療情報標準規格はその時代の背景技術に併せて進化してきました。それだけ実装技術の影響を受けていながら、医療情報標準規格についての議論は理念が中心となりがちで、背景となる技術が語られることはあまりありません。医療情報を取り扱う規格にはさまざまなものがあり、採用している技術によって向き不向きもあります。どのような場面で使われるべきか、あるいは使わざるべきかを決めるためには、その標準規格の背景となる技術について抑えておく必要が
サマリー システム構成の変遷 創業フェーズ はじめての API と技術選定 GraphQL 移行直前 GraphQL への移行を決めたきっかけ GraphQL 移行方針 移行期間 ふりかえり 1つ目の方針は正解だった 2つ目の方針は微妙だったかもしれないけど、正解だったかもしれない 3つ目の方針はやはり苦戦した さいごに サマリー サービス開始から3年経った Next.js + Rails なシステム 全ての API を REST から GraphQL にリプレース 約9ヶ月かかりました 早速フロントエンドの都合でバックエンドにも手を入れるということが減って快適です という話です。 システム構成の変遷 創業フェーズ 1人目エンジニアとして入社して、何から手を付けようかなーと考えた結果、事業の肝の部分からシステム化していくことにしました。弊サービス https://moneiro.jp/ は
注意:今回の記事で載せているコードは読者に具体的なコードのイメージを持たせる目的で書いている。それ故に、実際にブラウザ上で実行しても動作しない点には注意してほしい。より専門的ににGraphQLとRESTの違いを学びたいならLogRocketの記事とApolloの記事を参考に。 はじめに 今回の記事では、Web APIの開発に重宝されるRESTとGraphQLの違いを解説する。 対象とする読者 これからREST、またはGraphQLを実務で積極的に活用したいひと 両者の違いがわからないひと 個人開発等でWeb APIをつくるひと タイトルを見てなんとなく気になったひと APIとは RESTとGraphQLの議論に入る前に、まずはAPIについて説明する必要がある。 Wikipediaによると、API(Application Programming Interface)は以下のように定義されてい
※この投稿は米国時間 2022 年 12 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。 オンラインで、組み立て式のテーブルを注文したとします。ところが、パッケージを開けてみると、組立説明書が入っていません。完成品がどんなものかはわかっていても、それぞれのパーツをどう組み立てればいいのか、まるでわかりません。設計が不十分な API を使うコンシューマ開発者も、同じような経験をしているといえます。適切に設計された API なら、容易に見つけ、検索してアクセスし、使用することができます。高品質の API は、コンシューマ開発者がアイデアをひらめき、新しいユースケースを作り上げる手助けになってさえくれます。 もちろん、API 設計を改善する方法はあります。たとえば、RESTful のプラクティスに従うなどです。しかし、お客様が知らず知らずのうちに、ちょっとした不便
上の資料でも書いてるんですが、要点を言うと以下のようなことを主張している。 API の設計手法として、以下の2つのパターンが考えられる ・Resource-based API ・Usecase-based API Usecase-based というのは要はクライアントの要求にそのまま沿った形で API を作るということだ。しかし、UI やその他クライアントの要求というのは変わりやすいものなので、そのたびにいちいち API を変更しないといけないとか、API に一貫性がなくて使いにくいとか、1つの endpoint で多数の要求に対処する "神API" が作られてパフォーマンスが悪化する、というような問題が起こる。 したがって、注意深く RESTful API を設計すると Resource-based になる。ここで言っている Resource というのはテーブル設計にやや近いが、そのまま
Or you can return to our home page, or contact us if you can’t find what you are looking for.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く