#構造化データ

この記事を読んでまず思ったのは、MCPって派手な機能よりも、地味なメタ情報の積み重ねでかなり賢く見えるようになるんだな、ということだった。ツールを公開する仕組みとして見ると、名前と説明と入力スキーマがあれば最低限は足りそうに見える。でも実際には、クライアントが安心して使えるかどうかは、その先の「このツールは壊すのか、繰り返しても平気か、結果はどんな形で返るのか」といった周辺情報でかなり変わる。そこを丁寧に書けるのが面白い。 特に印象に残ったのは、tool annotations の考え方だ。`readOnlyHint` や `destructiveHint` みたいな値は、機能そのものを増やすわけではない。でも、クライアント側の振る舞いをかなり変えられる。たとえば、確認ダイアログを出すタイミングや、ユーザーに見せる並び順まで変わるかもしれない。ここで大事なのは、著者もはっきり書いているように、これはあくまで hint であって安全装置ではないことだと思う。AI 系の仕組みって、つい「賢く振る舞わせる」話に寄りがちだけど、最終的には認可や検証を別で持たないと危ない。その線引きを曖昧にしな

PDFや請求書、契約書、画像、音声、動画。こういう「人間なら読めるけど、機械にはつらい」素材を、きれいな表に変えるのは昔から面倒な仕事でした。しかも従来は、書類の形式ごとにテンプレートを作り、少しレイアウトが変わるたびに修正する必要があった。地味ですが、かなり消耗する作業です。 The New Stackの記事は、Amazon Bedrock Data Automationがこの悩みをかなり正面から壊しに来ている、と紹介しています。要するに、決まった型に当てはめるのではなく、foundation modelsを使って「散らかったデータ」を構造化されたデータへ変換する仕組みです。テンプレートに縛られないのが売りです。 Amazon Bedrock Data Automationは、PDFやメディアを構造化データに変える新しい仕組み 従来のテンプレート型抽出は、書式が少し変わるだけで壊れやすかった foundation modelsを使うことで、形式の違いに強くなれる 特に、請求書や契約書のような「毎回ちょっと違う文書」と相性がよさそう 人手での確認はまだ必要だが、前処理の手間はかなり減ら