Kumasoftの開発記録

【COLLEAGUE.SKILL入門】退職した同僚の「仕事の進め方」と「人柄」をAIに蒸留する実践セットアップガイド

2026-06-03T07:59:02.464+09:00

組織において、優秀なメンバーの退職や異動は、単なる人員の減少にとどまりません。彼らが培ってきた「仕事の進め方」や「判断基準」といった暗黙知が失われることは、組織にとって極めて大きな損失です。従来のドキュメント化やRAG（検索拡張生成）などの手法では、業務のプロセスは記録できても、その人独自の「思考モデル」や「コミュニケーションスタイル」までを完全に再現することは困難でした。

このような課題を解決するアプローチとして、上海人工知能実験室（Shanghai Artificial Intelligence Laboratory）のAI安全センターが主導するプロジェクト「COLLEAGUE.SKILL（現在はdot-skillへアップグレード）」が注目を集めています。本プロジェクトは、特定の人物の専門知識や対話スタイルを抽出し、AIエージェント向けのポータブルなスキルへと自動変換するシステムです。

GitHubでは約18,500〜18,900のスターを獲得し、コミュニティギャラリーには215のスキルや55のメタスキルが公開されるなど、すでに大きな実績を上げています。本記事では、このCOLLEAGUE.SKILLの仕組みを紐解き、実際に導入するための手順と初期設定例を解説します。

暗黙知と人柄を切り離す「二層構造（Dual Representation）」

COLLEAGUE.SKILLの最大の特徴は、対象者を単に丸ごとクローン化するのではなく、個人の「痕跡（Trace）」から有用な専門知識を抽出し、編集可能な技術的アーティファクト（スキル）として再利用する点にあります。

これを実現するために、システムは以下の2つの独立したトラックで動作を管理・制御します。これらは個別または統合して呼び出すことが可能です。

1. 能力（Capability）トラック：`work.md`

業務における手順、基準、思考モデル、意思決定の優先順位などを明文化して格納します。例えば、コードレビューにおける「N+1問題の指摘ルール」や「API設計の確認手順」などがこれに該当します。

2. 振る舞い（Behavior）トラック：`persona.md`

対象者の口調、表現の好み、対話の境界線、修正履歴などを格納します。業務に特化した冷静な口調や、特定の表現の癖などを制御します。

このように「能力」と「人柄」を分離することで、AIの挙動が不透明になることを防ぎ、ユーザーによる「検査可能（Inspectable）」「修正可能（Correctable）」な状態を確保しています。

導入手順：主要エージェントへのワンコマンドインストール

COLLEAGUE.SKILLは、複数のエージェント環境（Claude Code、Hermes Agent、OpenClaw、Codex）に対応しており、ワンコマンドでのインストールが可能です。

以下は、実際に「同僚（colleague）」プリセットを用いてセットアップを行うロードマップです。

ステップ1：データソースの準備

まずは蒸留の元となるデータを準備します。システムは日常の多様なデジタル活動データに対応しています。
* 自動収集：Slack（Bot経由）、飛書（Feishu - API/Wiki経由）、釘釘（DingTalk - ブラウザ経由）
* 手動収集：微信（WeChat）の暗号化データベース（SQLite形式）の書き出し、PDF、画像、メール（.eml/.mbox）、直接のMarkdown入力

ステップ2：エージェント環境へのインストール

例えば、Claude Code 環境に導入する場合、提供されているCLIツールを用いてインストールを行います。

# colleague-skill（dot-skill）をインストールし、エージェント環境へ適用するコマンド例
dot-skill install --agent claude-code

ステップ3：初期設定ファイルの作成

プロジェクトのルートディレクトリに、以下のような設定ファイルを配置します。ここでは「同僚（colleague）」プリセットをベースに、バックエンドエンジニアのスキルを定義する例を示します。

# config.yaml の設定例
skill:
  name: "backend_expert"
  preset: "colleague"
  source:
    - path: "./slack_exports/"
    - path: "./code_reviews.md"
  output:
    capability: "./skills/work.md"
    behavior: "./skills/persona.md"

生成される work.md と persona.md の記述例は以下の通りです。

# work.md (能力トラックの例)
- 意思決定の優先順位:
  1. APIのパフォーマンス（特にN+1問題の回避）
  2. 規定フォーマットの遵守
- 思考モデル:
  - コンテキストが不足している提案には、まず背景の説明を求める。

# persona.md (振る舞いトラックの例)
- 口調: 冷静かつ客観的、業務志向
- 表現の好み: 冗長な挨拶を省き、結論から述べる
- 修正履歴:
  - [2026-05-10] ユーザーのフィードバックに基づき、過度に攻撃的な表現を抑制するように修正。

よくあるエラーと対処法：対話を通じた継続的修正

実際に運用を開始すると、AIの回答が本人の実際の判断や口調とズレてしまうことがあります。COLLEAGUE.SKILLには、このズレを補正するための「修正・更新ループ（Correction & Update Loop）」が備わっています。

エラー1：判断基準が実際の業務と異なる場合

ユーザーが「彼女ならここで別の判断をするはずだ」と自然言語で指摘すると、システムは自動的にMarkdownパッチを作成し、work.md の能力記述を自動更新します。

エラー2：口調や振る舞いが不自然な場合

「彼はそんな冷たい言い方はしない」といったフィードバックに対しては、システムが構造化データ（{状況, 誤り, 修正}）として記録し、persona.md の振る舞いを補正します。これらは自動でバージョン管理やロールバックが可能です。

エラー3：不適切なプライバシー情報の露出

チャット履歴などから不要な個人情報が抽出されてしまった場合は、ローカル環境で直接Markdownファイルを開き、該当箇所を手動で削除・編集してください。本システムは成果物が明示的なファイル構造として出力されるため、安全にガバナンスを確保できます。

結論

COLLEAGUE.SKILL（dot-skill）は、単なるAIによるキャラクター模倣ツールではありません。組織の「暗黙知」という無形資産を、検査可能で編集可能な「技術的資産」へと変換するための強力なエコシステムです。

退職者が残したプロセスや思考の痕跡をAIに蒸留することで、組織の知識のポータビリティを高め、継続的な成長を支える基盤を構築できます。まずはローカルのプライベート環境での試行から始めてみてはいかがでしょうか。

MCP Appsの基本構造：Resources・Prompts・Toolsの役割分担からマルチエージェント、Smitheryへの展望

2026-06-01T07:43:40.224+09:00

LLM外部連携における「密結合」の限界とMCPの登場

現在のLLMアプリケーション開発において、外部データや既存システムとの連携は避けて通れません。しかし、これまでの開発手法では、特定のLLMやAPIに依存した「個別最適化された密結合なシステム」になりがちでした。クライアントごとに独自の統合コードを書く必要があり、システムの柔軟性や拡張性が著しく制限されていたのです。

この課題を解決するために登場したのが、Anthropic社が提唱した「Model Context Protocol（MCP）」です。MCPは、LLMと外部システム（コンテキスト）を接続するためのオープンな標準規格です。AIモデルとデータソースの間に標準化されたインターフェースを設けることで、一度構築した連携機能を多様なクライアントから再利用可能にします。ビジネスの視点から言えば、これはAI統合にかかる開発コストを劇的に削減し、システム全体のポータビリティを向上させるインフラの誕生を意味します。

3つの基本機能：Resources・Prompts・Toolsの設計思想

MCPの仕様は極めてシンプルでありながら、強力です。その根幹を支えるのが「Resources」「Prompts」「Tools」という3つの基本抽象概念です。これらは、LLMにコンテキストを提供する際の「関心の分離」を厳密に定義したものです。なぜこれらが分かれているのか、その設計上の意図とトレードオフを理解することが重要です。

Resources：安全性が担保された読み取り専用データ

「Resources」は、LLMがコンテキストとして自由に読み取ることができるデータ源です。データベースのレコード、ローカルファイル、APIの実行結果などがこれに該当します。

設計上の重要なポイントは、Resourcesが「読み取り専用（Read-only）」であり、「冪等性（何度実行しても結果が同じであること）」が期待されている点です。LLMに対してデータを提供する際、意図しないシステムの改ざんを防ぎつつ、必要なコンテキストを安全に供給するための防御壁として機能します。

Prompts：定型的なコンテキスト生成と制御の分離

「Prompts」は、LLMに対する指示のテンプレートをサーバー側で管理・提供する機能です。これにより、開発者はシステム特有のプロンプトエンジニアリングのノウハウを、クライアント側ではなくサーバー側に「カプセル化」できます。

クライアントは必要に応じてサーバーから最適なプロンプトテンプレートを取得し、動的なパラメータを流し込むだけで済みます。プロンプトの更新がシステム全体の再デプロイを伴わずに実行できるため、プロンプトのライフサイクル管理が非常に容易になります。

Tools：副作用を伴うアクションの実行

「Tools」は、外部システムの状態を変更する、あるいは動的な計算処理を実行するための「関数（Function）」をLLMに提供します。ファイルの書き込み、API経由でのデータ更新、特定コマンドの実行などがこれにあたります。

ToolsはResourcesとは異なり、システムに「副作用（Side effects）」をもたらします。そのため、セキュリティ設計上、実行前にユーザーの承認を挟む「Human-in-the-loop」の仕組みが推奨されます。この強力な権限移譲こそが、LLMを単なる「回答者」から「実行エージェント」へと進化させる鍵となります。

実装コードから学ぶMCPの構造

実際にMCPサーバーを構築する際の、Pythonを用いたシンプルな実装例を以下に示します。ここでは、公式が提供する「FastMCP」フレームワークを使用します。ResourcesとToolsがどのように区別され、定義されているかに注目してください。

from mcp.server.fastmcp import FastMCP

# MCPサーバーの初期化
app = FastMCP("System-Integration-Server")

# 1. Resourcesの定義（読み取り専用コンテキスト）
@app.resource("system://status")
def get_system_status() -> str:
    """システムのステータス情報を取得します（読み取り専用）"""
    # 実際にはDB参照やAPIコールなどを行う
    return "System Status: Normal. Database connection is active."

# 2. Toolsの定義（副作用を伴う書き込み処理）
@app.tool()
def update_user_role(user_id: str, role: str) -> str:
    """ユーザーのロールを更新します（副作用あり）"""
    # データベースの更新処理を想定
    print(f"Executing database update for user {user_id} with role {role}")
    return f"Successfully updated user {user_id} to role {role}."

このコードが示すように、デコレータを使い分けることで、システムに危害を加えない安全なデータ取得（@app.resource）と、慎重な取り扱いが必要な書き込み処理（@app.tool）が、コードレベルで明確に分離されています。LLMクライアントはこのスキーマを自動的に解釈し、適切に呼び出すことが可能になります。

マルチエージェントとパッケージ管理「Smithery」が拓く未来

MCPの登場により、AIエコシステムは「単一のエージェントによる対話」から「自律的なマルチエージェント連携」へと急速にシフトしています。複数の特化型MCPサーバーをオーケストレーターが束ねることで、複雑な業務プロセスを自動化するエコシステムが形成されつつあります。

このエコシステムの普及において重要なマイルストーンとなるのが、MCPサーバーのパッケージ管理ツール「Smithery」です。Smitheryは、Dockerコンテナ技術や各種設定を抽象化し、多様なMCPサーバーの発見、インストール、そしてデプロイを標準化します。開発者は手元で作成したMCPサーバーを迅速に共有し、他のシステムにシームレスに組み込めるようになります。これは、オープンソースのソフトウェアライブラリが現代の開発を爆発的に加速させたのと同様のダイナミズムを、AIコンテキストの領域にもたらします。

さらに、Next.jsなどを用いた独自エージェントUIの多様化も進んでいます。企業は自社専用のインターフェースを用意し、背後で稼働する複数のMCPエージェントと連携させることで、真に実用的な「AI駆動型アプリケーション」を内製化することが可能になります。

テクノロジーをシステムとして統合する

AIを単なる個人の生産性向上ツールとしてではなく、企業全体の「自律的なエコシステム」として捉え直す時期が来ています。MCPは、その基盤となる接続標準を提供するものです。Resources、Prompts、Toolsの役割分担を正しく理解し、適切に設計されたMCPサーバーを配置することは、変化の激しいAI技術に追従し続けるための最も賢明な投資となるでしょう。

ビジネスを加速するdocling活用ガイド：何ができるかと実践導入手順

2026-05-29T21:28:17.477+09:00

1. 現状の課題：LLM時代に立ちはだかる「ドキュメント前処理」の壁

エンタープライズ領域におけるAI活用、特に「RAG」（検索拡張生成）システムや「LLM」（大規模言語モデル）の社内導入において、最大のボトルネックとなるのが「PDFやOffice文書からの正確なテキスト抽出」です。多くの実務ドキュメントは、複雑なレイアウト、2段組の構成、表（テーブル）などを内包しており、従来の単純なOCRやテキスト抽出ツールでは、文章の構造やコンテキストが破壊されてしまうという課題がありました。

ドキュメントのレイアウト構造が崩れたままLLMに読み込ませると、ハルシネーション（事実に基づかない回答）の原因となります。このデータ前処理の課題を劇的に解決するオープンソースライブラリが、IBMによって開発された「docling」です。

2. 解決策：doclingがもたらすビジネス価値と技術的優位性

「docling」は、高度なドキュメント理解（Document Understanding）を実現するための次世代ライブラリです。PDF、DOCX、PPTXなどの多様なフォーマットに対応し、ドキュメントの視覚的要素を正確に解析します。

ビジネスにおける最大の導入価値は、手作業によるデータ整形コストの削減です。AIを単なる独立したソフトウェアとして利用するのではなく、組織内の多様な非構造化データを流動化させる「エコシステム」として機能させるために、doclingによる自動構造化は不可欠な基盤となります。

3. doclingの実践導入手順とコード例

ここでは、Python環境を用いたdoclingの具体的な導入手順と、実務で即座に使えるコード例を提示します。

3.1 環境構築

まずは、標準的なPython環境に「docling」をインストールします。

pip install docling

※doclingは、高度なレイアウト解析を行うために内部でディープラーニングモデル（PyTorchなど）を使用します。初回実行時にはモデルの自動ダウンロードが発生するため、十分なネットワーク帯域を確保してください。

3.2 基本的なMarkdown変換の実装

PDFファイルを読み込み、構造化された「Markdown形式」でテキストを抽出する最もシンプルな実装コードです。

from docling.document_converter import DocumentConverter

# コンバーターの初期化
converter = DocumentConverter()

# ローカルまたはURLのドキュメントを指定
source = "sample_business_report.pdf"
result = converter.convert(source)

# Markdown形式でエクスポート
markdown_content = result.document.export_to_markdown()
print(markdown_content)

このコードを実行するだけで、見出し、段落、箇条書きのリストが、適切なMarkdownタグを伴って抽出されます。

3.3 複雑な「表データ」の正確な抽出

従来のテキスト抽出ツールが最も苦手としていた「表（テーブル）」も、doclingは構造を維持したまま抽出可能です。

# 抽出されたドキュメント内のテーブルデータを個別に出力
for table in result.document.tables:
    # pandasのDataFrameとして出力し、データ分析やRAGに最適化
    df = table.export_to_dataframe()
    print(df)

4. 導入時における典型的なエラーと回避策

実務での開発・デプロイ段階において遭遇しやすい「つまずきポイント」とその対処法を解説します。

4.1 依存ライブラリの不足によるコンパイルエラー

WindowsやLinuxの一部のクリーン環境（Dockerコンテナなど）では、グラフィック処理ライブラリが不足しているために、インポート時にエラーが発生することがあります。

エラー例: ImportError: libGL.so.1: cannot open shared object file
対処法: Linux環境（Ubuntu/Debian系）では、以下のシステムライブラリを事前にインストールしてください。

sudo apt-get update && sudo apt-get install -y libgl1-mesa-glx libglib2.0-0

4.2 メモリ不足（OOM: Out of Memory）による強制終了

数百ページに及ぶ巨大なドキュメントや、高解像度の画像PDFを一度に処理しようとすると、メモリを過剰に消費してシステムがダウンすることがあります。

対処法: 処理するPDFのページ数をあらかじめ制限するか、処理時にシステムリソースの制限を設定します。実運用のパイプラインでは、ファイルを複数に分割してバッチ処理を行うロジックを実装することを推奨します。

5. 実務適用に向けたビジネスロードマップ

doclingの導入効果を最大化するために、以下のステップに沿って社内システムへの統合を推進してください。

アセスメント: 社内に散逸しているマニュアルや規定集、決算書などのドキュメントフォーマットを整理する。
パイプライン構築: doclingを用いた自動変換処理をAWS Lambdaやバッチサーバーに組み込み、定期的にMarkdown化する仕組みを作る。
ナレッジベース構築: 構造化されたMarkdownデータをチャンクに分割し、ベクトルデータベースに登録。これにより、社内情報を瞬時に検索可能な「超高性能RAG」を実現する。

文書の「正確なデータ化」こそが、これからのAI投資の成否を分ける極めて重要なインフラ投資となります。

RAGとLoRAの使い分け：LLMの知識拡張と個別最適化のアーキテクチャ

2026-05-17T09:13:27.284+09:00

はじめに：LLMの知識拡張における二つの選択肢

企業が生成AIを導入する際、直面する最大の壁は「モデルが自社の固有知識を持っていない」という点です。ChatGPTのような汎用LLMは高度な推論能力を持ちますが、機密性の高い社内文書や、直近の市場動向については学習していません。

この課題を解決するための主要なアプローチとして、外部知識を検索する「RAG（Retrieval-Augmented Generation）」と、モデルの挙動やトーンを微調整する「LoRA/QLoRA」が存在します。これらを単なる手段としてではなく、ビジネスの「知識管理戦略」という観点から比較・検討します。

RAG：外部データベースを「脳の外部メモリ」にする

RAGは、LLM本体を改変せず、社内文書などをベクトルデータベースに格納し、プロンプトのコンテキストとして渡す手法です。いわば「オープンブック試験」をモデルに行わせるような設計です。

なぜRAGを選ぶのか

情報の鮮度管理: データベースを更新するだけで知識を最新化できるため、頻繁に変わる社内ルールや市場データの扱いに適しています。
ハルシネーションの低減: 根拠となるドキュメントを提示できるため、モデルが事実に基づいた回答を行いやすくなります。
コスト効率: モデル本体を再学習するコストがかからないため、スタートアップや中規模プロジェクトでの導入に適しています。

LangChainを用いた実装の勘所

LangChainは、このRAGプロセスをパイプラインとして構造化するために最適です。例えば、以下の流れで実装します。

from langchain.vectorstores import Chroma
from langchain.chains import RetrievalQA

# ドキュメントをベクトル化してロード
vectorstore = Chroma(persist_directory="./db", embedding_function=embeddings)

# 検索と生成のパイプライン構築
qa_chain = RetrievalQA.from_chain_type(llm=llm, retriever=vectorstore.as_retriever())

# 実行
result = qa_chain.run("社内の有給休暇申請フローを教えて")

重要なのは「検索精度」です。ドキュメントの分割粒度や、検索エンジンに渡すクエリの最適化がシステムの質を決定します。

LoRA：モデルの「話し方」と「振る舞い」を個別最適化

一方で、「特定の出力形式を守らせたい」「専門的な文脈に沿った回答をさせたい」といったニーズには、モデル自体を微調整する「LoRA（Low-Rank Adaptation）」が有効です。

LoRAの技術的背景

LoRAは、全パラメータを更新する「Full Fine-tuning」とは異なり、モデルの重み行列に低ランク行列を挿入して加算する手法です。これにより、数％のパラメータを学習するだけで、元のモデルの知識を維持しつつ、特定のタスクに適応させることが可能です。特にメモリ消費を抑える「QLoRA」の登場により、民生用GPUでの学習も現実的な選択肢となりました。

使い分けの基準

タスクの複雑性: 言語生成のスタイルや専門用語の用法といった「振る舞い」を変えたい場合はLoRAが適しています。
知識の依存度: 新しい事実を覚えさせたい場合はRAGが勝ります。LoRAは知識の「暗記」には不向きであり、あくまで「推論能力のチューニング」と捉えるべきです。

どちらを選ぶべきか：設計の意思決定

実務において、これらは二者択一ではありません。多くのエンタープライズ環境では「RAGで専門知識を供給し、LoRAで回答のトーンと精度を担保する」というハイブリッドな構成が理想的です。

設計の際は、まずはRAGを実装し「知識の欠落」を埋めることから始めてください。その上で、回答の構造が安定しない、特定の社内フォーマットに従わないといった「出力の品質」に課題を感じた段階で、LoRAによる微調整を検討するロードマップが、最も失敗の少ないアプローチです。

AIを単なるツールとして利用するのではなく、組織内の知識エコシステムとしてどのように組み込むか。そのアーキテクチャの選択こそが、技術導入の成否を分ける鍵となります。

FastMCPで学ぶ：AIエージェントに自作ツールを実装する最短ルート

2026-05-15T22:02:09.537+09:00

AIエージェントの拡張性を左右する「MCP」という選択肢

現代のAIエージェント開発において、モデル自体の性能向上はもはや前提条件です。現在のエンジニアが直面している真の課題は「LLM（大規模言語モデル）にいかにして外部の専門知識や操作権限を安全かつ効率的に与えるか」という点に集約されます。これまで、LangChainやLlamaIndexなどを利用して個別にツールを実装してきましたが、接続先ごとに異なる実装コストは開発の障壁となっていました。

そこで登場したのが「Model Context Protocol（MCP）」です。MCPは、AIアプリケーションと外部システムを接続するための標準化されたプロトコルです。今回は、PythonでMCPサーバーを構築するための最短ルートである「FastMCP」に焦点を当て、AIエージェントに自作ツールを組み込む本質的な意義を深掘りします。

FastMCPによるツール実装のメカニズム

FastMCPは、標準的なPythonの型ヒントとデコレータを活用することで、開発者が煩雑なプロトコル定義を意識することなくツールを作成できるライブラリです。なぜこの抽象化が重要なのでしょうか。

通常、LLMにツールを認識させるためには、関数名だけでなく、引数の型や役割を記述した「JSONスキーマ」を生成し、モデルに提示する必要があります。FastMCPの@mcp.toolデコレータは、Pythonの関数定義から自動的にこのメタデータを抽出します。

シンプルな計算ツールによる実装例

以下のコードは、FastMCPを用いた基本的な計算ツールの実装例です。

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("MyCalculator")

@mcp.tool()
def add(a: int, b: int) -> int:
    """2つの数値を加算するツール"""
    return a + b

if __name__ == "__main__":
    mcp.run()

このコードの核心は、docstring（関数の説明文）がそのままLLMに対する「推論のヒント」として機能する点にあります。LLMはプロンプトを通じてこの関数名や説明文を読み取り、いつそのツールを呼び出すべきかを判断します。つまり、コードの可読性がそのままAIの推論精度に直結するという「AIファースト」な設計がなされているのです。

メタデータが精度を高める理由

AIエージェントがツールを選択する際、LLMは提供されたメタデータに基づいて「確率的な判断」を行います。もし引数の説明が曖昧であれば、モデルの推論は不安定になります。FastMCPを使用する際は、単に動くコードを書くのではなく、以下の要素を意識してください。

関数名の明確化：LLMが直感的に理解できる命名にする。
型ヒントの厳密化：intやstrを正しく定義し、バリデーションを効かせる。
docstringの最適化：ツールを実行する際の「目的」や「制約」を自然言語で補足する。

これにより、LLMは「この関数を呼び出すことで、目的のタスクにどう貢献できるか」という文脈（Context）を正しく理解し、誤作動を抑止できるのです。

Claude Desktopへの統合設定

構築したFastMCPサーバーを、日常的なワークフローで利用できるようにしましょう。Claude Desktopアプリの設定ファイル（claude_desktop_config.json）を編集することで、自作ツールをローカルのAI環境に統合できます。

{
  "mcpServers": {
    "my-calculator": {
      "command": "uv",
      "args": ["run", "calculator.py"]
    }
  }
}

この設定により、Claude Desktopが起動するたびにMCPサーバーがバックグラウンドで立ち上がり、LLMが自作した計算ツールを透過的に利用可能となります。これは単なるプラグインの追加ではなく、AIエージェントが「外部の道具を自律的に選んで使う」という新しいエコシステムへの入り口です。

MCPという標準化された基盤の上にツールを実装することは、将来的にモデルが入れ替わっても再利用可能な資産を構築することと同義です。技術の細部にこだわりつつ、常に高い視座で「AIエージェントと人間がいかに協働するか」というインターフェース設計を追求してください。

次世代AIエージェント基盤：ローカルLLMとMCPを融合させた高セキュリティ環境の構築

2026-05-14T07:46:07.813+09:00

はじめに：クラウド依存からの脱却とローカル環境の再定義

現代のAI開発において、企業やエンジニアは「利便性」と「プライバシー」の板挟みにあります。ChatGPTやClaudeといったクラウド型LLMは圧倒的な性能を誇る一方、機密データや個人情報を外部APIに送信するリスクは無視できません。そこで注目されているのが、ローカルLLMと「Model Context Protocol（MCP）」を組み合わせた次世代のAIエージェント基盤です。

本記事では、外部に依存しないセキュアなAIエコシステムを構築するためのアーキテクチャ設計と、その背景にある技術的思想を深掘りします。

1. なぜ「ローカルLLM × MCP」なのか

AIを単なるツールではなく「エコシステム」として捉えると、情報の集約拠点（コンテキスト）と処理系（推論）の分離が重要になります。

従来のRAG（検索拡張生成）システムは、モデルごとに独自のデータコネクタを実装する必要がありました。しかし、Model Context Protocol（MCP）は、クライアント（AIアプリ）とサーバー（データソース）間の通信を標準化するオープンなプロトコルです。これにより、一度構築したツール群を、モデルを変更しても再利用可能になります。

2. アーキテクチャの設計思想とトレードオフ

ローカル環境での構築において直面する最大の課題は「計算リソース」と「性能」のトレードオフです。

推論エンジン：Ollama
Ollamaは、Llama 3やMistralといった強力なオープンソースモデルをローカルで即座に実行可能な環境を提供します。量子化技術を用いることで、コンシューマー向けGPUでも十分な実用速度を確保できます。
データインターフェース：MCPサーバー
MCPサーバーは、ローカルのファイルシステムやデータベースをLLMが理解できる形で提供します。クラウドAPIを叩く代わりに、ローカルのMCPサーバーがSQLやファイル操作を実行し、結果をコンテキストとしてLLMに渡す仕組みです。

3. 実践：ローカル環境構築のステップ

まずは、Ollamaでモデルを起動し、MCPサーバーと接続する最小構成を構築します。

手順1：Ollamaの起動

まずはターミナルでローカルサーバーを立ち上げます。

ollama serve
ollama run llama3

手順2：MCPサーバーの定義（Python例）

MCP公式SDKを使用して、ローカルファイルを読み込むシンプルなサーバーを作成します。

from mcp.server.fastmcp import FastMCP

# サーバーの初期化
mcp = FastMCP("LocalFileServer")

@mcp.tool()
def read_local_config(path: str) -> str:
    """ローカルの設定ファイルを安全に読み込むツール"""
    with open(path, "r") as f:
        return f.read()

if __name__ == "__main__":
    mcp.run()

このコードにより、ローカルLLMは「設定ファイルを読み込む」というタスクを、安全なインターフェース経由で実行可能になります。外部通信が遮断された環境下で、AIはローカルのドキュメントを直接参照して推論を行えるようになります。

4. セキュリティとガバナンスの観点

ローカル環境の構築は、データの「境界線」を明確にする行為です。クラウドAPIを利用する場合、データは暗号化されていても通信経路やベンダーのポリシーに依存します。ローカルLLMとMCPを組み合わせる手法は、データがホストマシンから一切流出しない「クローズドなループ」を実現します。

ただし、利便性とのトレードオフとして、モデルのアップデートや計算リソースの維持管理は自前で行う必要があります。これは「運用の手間」と「情報の主権」を天秤にかける意思決定といえます。

今後の展望

AIエージェントの未来は、特定のプラットフォームに依存することなく、標準化されたプロトコルを通じてデータと推論モデルが自由に連携する世界にあります。MCPはそのプロトコル層を担う重要なピースです。まずは小規模なツールからMCP対応を進め、自社専用のプライベートAIエコシステムを構築することをお勧めします。

実用レベルへ引き上げる！カスタムスキル開発の基礎と設計パターン

2026-05-12T21:37:19.752+09:00

AIエージェントを「実用」へと引き上げるカスタムスキルの重要性

現在、多くの企業がLLM（大規模言語モデル）を導入していますが、汎用的なチャットボットを利用するだけでは、自社の業務プロセスに深く食い込むことは困難です。既存の公開ツールでは解決できない「現場特有の業務」をこなすためには、AIエージェントに独自の機能を付与する「カスタムスキル」の実装が不可欠です。

AIエージェントの真価は、単なる知識の参照にとどまらず、外部ツールや社内システムと連携して「行動」を起こせる点にあります。本稿では、カスタムスキルを設計する際の主要なパターンと、実用レベルへ引き上げるためのロードマップを解説します。

カスタムスキルとは何か：エージェントの拡張機能

カスタムスキルとは、AIが自身の判断で呼び出せる「外部実行可能な関数」を指します。AIが回答に詰まったとき、あるいは特定のデータを取得する必要があるときに、定義された関数を引数付きで呼び出す仕組みです。これを「Function Calling」と呼びます。

カスタムスキルを活用することで、AIは以下の領域へ進出できます。
- 社内データベースからの情報照会
- 特定のWeb APIを介した顧客管理システムとの連携
- 業務システム上のデータ更新作業

カスタムスキル設計の基本パターン

カスタムスキルを実装する際には、以下の3つの設計パターンを理解することが、システムの堅牢性を高める鍵となります。

1. 情報参照型（Read-Only）

社内のドキュメント検索やデータベース照会を行うパターンです。エージェントがユーザーの質問に対し、リアルタイムな社内情報を付加して回答を作成します。RAG（Retrieval-Augmented Generation）の精度向上に直結します。

2. アクション実行型（Write/Execute）

カレンダー登録やメール送信、API経由でのタスク実行を行うパターンです。この場合、AIが誤った操作をしないよう、「承認プロセス」を挟むことが重要です。

3. データ加工・集計型（Transformer）

複雑な計算や、複数のソースから取得したデータの整形を行うパターンです。LLM自体の計算能力に頼らず、専用のコードを叩くことで精度を担保します。

Pythonによるカスタムスキルの実装例

ここでは、特定のWeb APIを叩いて情報を取得する基本的な関数の例を紹介します。LangChainなどのフレームワークを用いると、これらの定義をエージェントに簡単に組み込むことが可能です。

def get_sales_data(target_date: str) -> str:
    """
    指定された日付の売上データを社内APIから取得します。
    """
    # ここにAPIリクエスト処理を記述
    import requests
    response = requests.get(f"https://api.company.com/sales?date={target_date}")
    return response.json() if response.status_code == 200 else "データ取得失敗"

この関数をエージェントに渡す際、関数名だけでなく、引数の説明（docstring）を詳細に記述することが不可欠です。LLMは、このドキュメントを読んで「どのタイミングで、どの引数を使うべきか」を判断するためです。

実用レベルへ引き上げるための3ステップ

カスタムスキルを趣味のプロトタイプから業務ツールへ昇格させるには、以下のステップが重要です。

境界線の定義: AIが実行可能な権限を最小限に絞り込む（最小権限の原則）。
エラーハンドリングの強化: APIが落ちていた場合や、不正な引数が渡された場合でも、AIが適切にリカバリできる出力を設計する。
人間による介入（Human-in-the-loop）: 重要性の高いアクションについては、必ず人間の承認を経て実行される設計を採用する。

結論：エージェントはツールではなく「エコシステム」である

カスタムスキルを定義することは、AIエージェントに「手足」を与えることと同義です。単なる会話型のチャットボットから、業務を自動化するエコシステムへと進化させるためには、このカスタムスキル開発が最も重要なプロセスとなります。

まずは、特定の小さな業務一つに絞ってカスタムスキルを実装し、そこから徐々に連携範囲を広げていくアプローチを推奨します。技術の進化を待つのではなく、自らの環境に合わせたカスタムスキルを設計することこそが、次世代の業務効率化における最大の差別化要因となります。

AIエージェントの「スキル」とは？仕組みから実装の基本までを完全網羅

2026-05-11T07:45:26.779+09:00

はじめに

近年の生成AIの進化により、単なる「対話型AI」から、自律的にタスクを遂行する「AIエージェント」への注目が急速に高まっています。AIエージェントが従来のチャットボットと決定的に異なる点は、外部ツールを能動的に操作し、複雑なワークフローを完遂できる「自律性」にあります。この自律性を支える中核機能が「スキル（ツール）」です。

本稿では、AIエージェントにおけるスキルの概念から、その仕組み、そしてLangChainを用いた実装の基本までを体系的に解説します。これからエージェント開発を志すエンジニアにとって、実装の全体像を把握する地図としてご活用ください。

AIエージェントにおける「スキル」とは

AIエージェントのスキルとは、LLM（大規模言語モデル）がタスク解決のために呼び出す「外部機能」を指します。LLMは言語処理能力には長けていますが、リアルタイムの検索、計算、データベース操作、API連携といった外部環境への直接的な干渉は行えません。

スキルを実装することで、LLMは「推論エンジン」として振る舞い、必要なときに外部ツールという「手足」を動かすことが可能になります。これはAIを単なる知能ではなく、実行力を持つ「エコシステム」へと昇華させる重要な仕組みです。

スキル実行のメカニズム

エージェントがスキルを実行するプロセスは、主に以下のサイクルで構成されます。

タスクの分解と計画: ユーザーの入力を受け、LLMが目標達成のために必要な手順を推論します。
スキルの選択: 利用可能なスキルの中から、現状の目標に最適なものをLLMが動的に選択します。
実行とフィードバック: 選択されたスキルが実行され、その結果が再びLLMにフィードバックされます。
終了判定: 結果が不十分であれば再度ステップ1〜3を繰り返し、達成できれば回答を生成します。

このループが回ることで、エージェントは未知のタスクに対しても柔軟に対応できるようになります。

LangChainによる実装の基本ステップ

業界標準のフレームワークである「LangChain」を用いると、スキルの定義とエージェントへの組み込みが非常に直感的になります。以下は、簡単な検索機能をエージェントに実装する際の構成案です。

1. ツールの定義

まずは、エージェントが実行可能な関数を定義します。

from langchain.tools import tool

@tool
def get_weather(location: str) -> str:
    """指定した場所の天気を取得するツール"""
    # 実際にはここで外部APIを呼び出す
    return f"{location}は晴れです。"

tools = [get_weather]

2. LLMのバインドとエージェント構築

次に、モデルにツールを認識させ、エージェントを実行可能な状態にします。

from langchain_openai import ChatOpenAI
from langgraph.prebuilt import create_react_agent

model = ChatOpenAI(model="gpt-4o")
# ReAct形式のエージェントを構築
agent_executor = create_react_agent(model, tools)

3. 実行

エージェントは入力内容に基づき、自らget_weatherを選択して実行します。

response = agent_executor.invoke({"messages": [("user", "東京の天気は？")]})
print(response["messages"][-1].content)

実装における注意点

エージェント開発において重要なのは「スキルの設計」です。以下の点に留意してください。

目的を明確にする: スキルの説明（docstring）を曖昧にすると、LLMが誤った選択をする確率が高まります。
安全性と権限管理: 外部APIを操作する場合、エージェントが意図しない操作をしないよう、最小権限の原則に基づいた設計が不可欠です。
エラー処理: スキル実行に失敗した場合の情報をLLMに適切にフィードバックし、再試行させる仕組みを構築してください。

まとめ

AIエージェントのスキルは、AIが現実世界で価値を生むための架け橋です。LLMによる推論と外部スキルの統合は、今後のソフトウェア開発のスタンダードになると予測されます。

まずはシンプルな関数をツールとして登録するところから始めてみてください。エージェントが自らの判断でツールを使いこなす様子を目の当たりにすれば、その可能性と課題がより具体的に見えてくるはずです。体系的な理解を土台に、ぜひ高度なエージェント開発に挑戦してください。

AIエージェントの「手足」を作る：スキル実装の基礎と仕組みを完全網羅

2026-05-10T11:21:38.855+09:00

はじめに

近年の生成AI技術の進化により、単なるテキスト生成を超え、自律的にタスクを遂行する「AIエージェント」が注目を集めています。AIエージェントが単なるチャットボットと決定的に異なるのは、外部環境と対話し、具体的な作業を実行するための「手足」となるスキル（Tool Use）を備えている点です。

本記事では、AIエージェントにスキルを実装するための基礎的な仕組みから、LangChainを用いた実践的な開発手法まで、体系的に解説します。エージェントを構築するエンジニアにとっての「地図」として、開発の指針となれば幸いです。

AIエージェントにおける「スキル」の役割

AIエージェントにおけるスキルとは、LLM（大規模言語モデル）が自然言語の推論結果に基づき、外部APIや関数を呼び出す仕組みのことです。モデル自身には実行できない計算、検索、ファイル操作といった機能を、外部ツールとして定義し、必要な場面でモデルが自ら「選択」して呼び出します。

このプロセスは、以下のステップで進行します。
1. ユーザーからの指示を受領
2. 推論に基づき必要なツールを特定
3. ツールの引数を生成
4. ツールを実行し、結果をLLMへフィードバック

このサイクルを繰り返すことで、複雑なマルチステップタスクの自動化が可能となります。

スキル実装の仕組み：Tool Useの基盤

現在のLLMにおいて、ツール呼び出しを支える技術は「Function Calling」です。モデルに対して「利用可能な関数のリスト」と「その説明」をプロンプトまたは構造化データとして提供することで、モデルは指定された形式で関数をコールするようになります。

正しくツールを認識させる「Docstring」の重要性

エージェントがどのタイミングでどのツールを使うべきかを判断するためには、記述（Docstring）の質が鍵となります。LLMは、関数名そのものよりも、関数が「何を行い」「どのような引数が必要か」という説明文を重視します。

何を行う関数か（例：検索結果を取得する）
引数の型と役割は何か（例：検索クエリ文字列）
どのような戻り値が返るか

これらを簡潔かつ明確に記述することで、モデルの誤作動を防ぎ、精度を高めることが可能です。

LangChainによる実装例

Python環境において、LangChainを用いることでツール定義を効率的に行えます。以下は、検索ツールを実装する標準的なステップです。

from langchain.tools import tool

@tool
def get_weather(location: str) -> str:
    """指定した場所の現在の天気を取得するツールです。引数には都市名を指定してください。"""
    # 本来はここで外部APIを呼び出す
    return f"{location}の天気は晴れです。"

# ツールのリスト化
tools = [get_weather]

このように、@toolデコレーターを付与することで、LangChain側で必要なスキーマ定義が自動的に生成されます。あとは、このリストをAgentExecutorに渡すだけで、モデルは自律的にツールを判断し実行できる状態になります。

開発時のベストプラクティス

スキル実装を成功させるために、以下の3点に留意してください。

単機能の徹底: 一つのツールは一つの機能に限定してください。多機能すぎる関数は、LLMの判断ミスを招く原因となります。
エラーハンドリング: ツール実行中に失敗した場合、その結果をそのままLLMに伝えることが重要です。「エラーが発生した」という事実をエージェントにフィードバックすることで、再試行や代替案の検討を自律的に行わせることができます。
監視とログ: どのステップでどのツールが呼び出されたかを記録してください。LangSmithなどのツールを活用し、推論のプロセスを可視化することが、デバッグの近道です。

まとめ

AIエージェントのスキル実装は、単なるプログラミングの域を超え、LLMという「知能」に物理的なインターフェースを与える設計作業です。ツールの定義、説明文の最適化、そして適切な呼び出しサイクルの構築を行うことで、AIは強力な業務パートナーへと進化します。

今回紹介した基礎概念を足掛かりに、まずはシンプルなツール作成から始めてみてください。エージェントをエコシステムとして捉え、多様な機能をつなぎ合わせることで、自動化の可能性は飛躍的に拡大するはずです。

FastMCPで体験する「ツール開発の民主化」：独自LLMツールをClaude Desktopで動かす最短手順

2026-05-09T08:15:25.274+09:00

AIエージェントを拡張する「標準規格」の到来

LLM（大規模言語モデル）の進化に伴い、AIエージェントの価値は「モデルそのものの知能」から「外部システムとどう連携するか」というエコシステムの構築へとシフトしています。しかし、これまでAIに独自のツールを使わせる開発は、APIの認証管理やプロンプトエンジニアリングの複雑さゆえに、専門エンジニアの領域でした。

そこで注目すべきが、Anthropicが提唱する「Model Context Protocol（MCP）」です。MCPは、AIと外部データ・ツールを接続するための標準規格です。本記事では、Python SDKである「FastMCP」を用いて、誰でも直感的にAIツールを作成・運用する方法を解説します。

FastMCPが実現する「開発の民主化」

FastMCPの最大の革新は、記述の簡素化にあります。従来、ツール定義にはJSON Schemaなどの複雑なメタデータ記述が必要でしたが、FastMCPはPythonの「Docstring」を自動的にAIの仕様書として解釈します。

from mcp.server.fastmcp import FastMCP

# サーバーの初期化
mcp = FastMCP("MyTools")

@mcp.tool()
def add(a: int, b: int) -> int:
    """2つの数値を加算します"""
    return a + b

この数行のコードだけで、LLMはaddという関数が何を意味し、どのような引数を期待しているかを即座に理解します。なぜこれが重要かといえば、インターフェースの記述コストを極限まで下げることで、AIエージェントを「個人の生産性向上ツール」へと変貌させられるからです。

Claude Desktopへの接続：ベストプラクティス

作成したツールを実戦投入するには、Claude Desktopの設定ファイルにMCPサーバーを登録する必要があります。これにより、ClaudeのUIから直接自作関数を呼び出すことが可能となります。

設定ファイル claude_desktop_config.json に以下のように追記します。

{
  "mcpServers": {
    "my-custom-tool": {
      "command": "uv",
      "args": ["run", "main.py"]
    }
  }
}

ここで重要なのは、実行環境の分離です。uvやpipxを活用し、仮想環境を明示的に指定することで、ホストOSを汚染することなくセキュアにツールを提供できます。この「分離と接続」という設計思想は、エンタープライズレベルでのAI活用においても不可欠な要素です。

なぜ今、MCPを学ぶべきか

これまで、AI開発はモデルを微調整（ファインチューニング）するか、プロンプトを工夫するかに偏っていました。しかし、真のAI活用は「必要な情報を正しい形式でAIに渡す」というインフラの構築にあります。MCPは、AIと業務システムを疎結合に繋ぐ「APIの共通言語」としての役割を果たします。

公式ドキュメント（modelcontextprotocol.io）でも強調されているように、標準化が進むことで、一度書いたツールは将来的にClaude以外のLLMインターフェースでも活用可能になります。今、この新しいパラダイムに乗ることは、将来的なエンジニアリングの生産性を劇的に向上させる投資となります。

まとめ：ツールを自ら定義する時代へ

FastMCPによるツール開発は、もはや大規模なプロジェクトを必要としません。Pythonの関数を定義し、それを標準プロトコルで公開する。このシンプルな反復こそが、AIエージェントを「賢いチャットボット」から「自律的な作業者」へと進化させる鍵となります。

まずは手元の単純なタスクをツール化し、Claude Desktopに接続してみてください。AIと共に働く体験が、昨日までとは全く異なるものになるはずです。

Claude Desktop連携の裏側：MCP設定ファイルが制御するエージェントと外部データ接続の仕組み

2026-05-08T18:48:35.539+09:00

Claude Desktopを「MCP Host」として再定義する

近年のLLMエコシステムにおいて、AIモデルは単なる「チャットボット」から、外部環境と相互作用する「エージェント」へと進化を遂げています。Anthropicが提唱する「Model Context Protocol（MCP）」は、まさにこの進化を加速させる標準化プロトコルです。

これまで、LLMにローカルのファイルシステムやデータベースを接続するには、個別のプラグインや複雑なAPI実装が必要でした。MCPの登場により、私たちは「MCP Host」と「MCP Server」という分離されたアーキテクチャを通じて、AIの能力をモジュール化・拡張できるようになったのです。

MCP設定ファイルの裏側：サーバーのライフサイクル管理

Claude DesktopがMCP Hostとして機能する際、その制御の要となるのがclaude_desktop_config.jsonです。このファイルは、Claude起動時にどのような外部サーバーを呼び出し、どう通信を確立するかを定義する「設定のロードマップ」といえます。

以下は、自作サーバーを接続する際の標準的な設定例です。

{
  "mcpServers": {
    "my-custom-server": {
      "command": "node",
      "args": ["/path/to/server.js"]
    }
  }
}

この設定において、Claude Desktopは以下のプロセスを遂行します。

プロセスの起動: 設定ファイル内のcommandとargsに基づき、標準入出力（stdio）を介してサーバーをサブプロセスとして立ち上げます。
ハンドシェイクの確立: JSON-RPCプロトコルを用いて初期化を行い、サーバーが提供可能な「機能のメタデータ」を交換します。
監視と維持: Claude Desktopは親プロセスとして、サーバーのライフサイクルを監視します。サーバーが予期せず終了した場合、適切に再接続を試みるなど、堅牢な運用が担保されています。

MCPの3要素を理解する：Resources, Tools, Prompts

MCPが提供する強力な抽象化レイヤーは、主に3つの要素で構成されています。これらを理解することは、実用的なAIエージェントを構築する上で不可欠です。

1. Resources（リソース）

AIが参照する「読み取り専用のデータ」です。例えば、ローカルのログファイルやドキュメントを「リソース」として公開することで、AIはモデルのコンテキストウィンドウにそれらを取り込み、分析することが可能になります。

2. Tools（ツール）

AIが実行する「能動的なアクション」です。関数の定義とその入出力スキーマを提供することで、AIはコード実行、API呼び出し、システム操作などを自律的に判断して実行します。

3. Prompts（プロンプト）

再利用可能な「テンプレート群」です。特定のタスクに対する指示やコンテキストの構成をあらかじめ定義しておくことで、ユーザーは一貫した品質の出力を引き出すことができます。

実践：AIエージェント基盤としての可能性

MCPを採用する最大のメリットは、AI側の実装を一切変更することなく、サーバー側の機能追加だけでAIの能力を拡張できる「疎結合な設計」にあります。これは、マイクロサービスアーキテクチャのAI版とも呼ぶべき概念です。

例えば、社内DBの情報を検索するサーバーと、Slackに投稿するツールサーバーを別々に準備しておけば、Claude Desktopを通じてこれらを動的に組み合わせて業務フローを自動化できます。AIを特定の「ツール」として使うのではなく、MCPを通じて広大なエコシステムと接続する「インターフェース」として捉え直すことが、次世代のエージェント開発の鍵となります。

まとめ

Claude DesktopとMCPの連携は、AIを閉じた環境から解放し、実社会のデータやワークフローと密接に結びつけるための重要な橋渡しです。設定ファイルが担うライフサイクル管理の仕組みを理解し、Resources・Tools・Promptsという構成要素を最適に設計することで、私たちはより深く、より実用的なAIエージェント基盤を構築することができます。

まずは手元の小さなツールをMCPサーバーとして実装し、Claude Desktopに認識させることから始めてみてください。それが、AIエージェント開発の第一歩となります。

TypeScriptで実装するMCP Server：Stdioトランスポートを介したAIとのセキュアな対話

2026-05-07T22:28:21.420+09:00

はじめに：AIエージェントの可能性を拡張するMCP

近年のAI開発において、LLM（大規模言語モデル）の進化は目覚ましいものがありますが、単独のモデルがすべての情報を保持することは不可能です。そこで重要となるのが「Model Context Protocol（MCP）」です。MCPは、AIモデルとデータソースを標準化されたプロトコルで接続するためのオープンフレームワークであり、AIを単なる対話ツールから、ローカルデータや業務システムを自在に操作する「エージェント」へと進化させる鍵となります。

本稿では、TypeScriptを用いてMCPサーバーを構築し、Stdioトランスポートを介した安全なデータアクセスの仕組みを深掘りします。

なぜStdioトランスポートなのか：設計上のトレードオフ

MCPサーバーには、HTTPやSSE（Server-Sent Events）などの通信方式がありますが、今回採用する「Stdioトランスポート」には特筆すべき利点があります。それは、ホストプロセスと子プロセスとしてMCPサーバーが直接通信するため、ネットワークポートを開放する必要がなく、ファイアウォールの制約を受けないという「高いセキュリティ」と「低レイテンシ」の両立です。

外部ネットワークを経由しないため、機密性の高いローカルファイルや社内データベースへのアクセスを、安全かつ閉じた環境で実現できます。これは、エンタープライズ環境でエージェントを導入する際の必須要件とも言えます。

TypeScriptでのMCPサーバー構築：実践ステップ

MCPサーバーの構築には公式の「@modelcontextprotocol/sdk」を利用します。以下の手順で、極めてシンプルにサーバーを立ち上げることができます。

1. 依存関係のインストール

npm install @modelcontextprotocol/sdk

2. サーバー実装の基本形

以下のコードは、JSON-RPCを介してクライアントからツールを呼び出せるようにする最小構成です。

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { CallToolRequestSchema, ListToolsRequestSchema } from "@modelcontextprotocol/sdk/types.js";

const server = new Server({ name: "my-local-server", version: "1.0.0" }, { capabilities: { tools: {} } });

// 利用可能なツールの定義
server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [{
    name: "get_system_info",
    description: "システムのステータスを取得します",
    inputSchema: { type: "object", properties: {} }
  }]
}));

// ツールの実行ロジック
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === "get_system_info") {
    return { content: [{ type: "text", text: "System status: OK" }] };
  }
  throw new Error("Unknown tool");
});

const transport = new StdioServerTransport();
await server.connect(transport);

3. JSON-RPCによるフローの仕組み

MCPは背後で「JSON-RPC 2.0」を活用しています。クライアント（AIエージェント）がリクエストを送ると、Stdio経由でサーバーがJSONメッセージとして受け取り、定義されたスキーマに従って処理を実行します。この標準化されたやり取りにより、AIはデータの構造を即座に理解し、正確な操作を行うことが可能となります。

セキュアな運用のために

ローカルでデータを扱う際、もっとも注意すべきは「認証」と「認可」です。MCPサーバーを構築する際は、以下の観点を意識してください。

最小権限の原則: サーバーに付与するツールは、必要最小限の機能に留めてください。
入力のバリデーション: AIが生成する引数は必ず検証を行い、コマンドインジェクションなどを防ぐ必要があります。
環境変数の隔離: APIキーやシークレットは.envファイルを用い、サーバープロセスからのみ読み取れるように設計します。

まとめ：AIとローカル環境を接続する新たなエコシステム

MCPの登場により、AIエージェントは「知識」だけでなく「ツール」という手足を手に入れました。TypeScriptを用いたStdioベースのサーバー構築は、その第一歩であり、最も堅牢な実装パターンの一つです。

今後は、さらに複雑なビジネスロジックをMCP経由で提供することで、AIが自律的に業務を遂行する環境が当たり前になるでしょう。まずは今回紹介した基礎をベースに、皆様のプロジェクトに必要なデータ連携を試してみてください。詳細は公式ドキュメント（modelcontextprotocol.io）でも随時更新されていますので、併せて参照することを強く推奨します。

「指示待ち」から「自律実行」へ：AIエージェントで業務を自動化する実践ワークフロー

2026-05-06T20:50:40.563+09:00

AIトレンドの転換点：チャットから「自律エージェント」へ

近年の生成AIの進化は、単なる「対話型AI」の枠を超えようとしています。これまで、私たちはプロンプトを打ち込み、回答を待つ「指示待ち」のスタイルでAIを活用してきました。しかし、現代のAIの潮流は、タスクを自律的に遂行する「AIエージェント」へと移行しています。

AIエージェントとは、明確な目標を与えられると、自身で必要なツールを選択し、Web検索やデータ収集、コードの実行、検証を繰り返してゴールに到達する仕組みです。この構造の根幹にあるのが、LLM（大規模言語モデル）の推論能力と、外部ツールを組み合わせる「エコシステム」としての視点です。

なぜ今、エージェント化が必要なのか

従来のチャットボットでは、複雑な業務を一貫して完遂することは困難でした。マルチステップの業務では、人間がその都度出力を確認し、次のプロンプトを入力する必要があったからです。この「人間がボトルネックになる構造」を打破するのがエージェントの目的です。

- **効率化の限界突破**: 作業の切り替えによる集中力の低下を防ぎます。

- **精度の向上**: RAG（検索拡張生成）技術を組み合わせることで、最新情報に基づいた根拠のある回答を生成可能です。

- **スケーラビリティ**: 一度ワークフローを設計すれば、再現性高く業務を自動化できます。

実践ワークフロー：LangChainとCursorによる構築

AIエージェントを構築する際、現在最も強力な選択肢となるのが「LangChain」を用いたワークフロー構築と、「Cursor」による開発環境の統合です。

1. タスク分解と計画策定

エージェントの設計判断において最も重要なのは、複雑な課題を「小さなサブタスク」に分解する能力です。LangChainの「ReAct」フレームワーク（Reason + Act）を導入することで、AIは「思考・行動・観察」というループを自律的に回し始めます。

2. 具体的な実装ステップ

以下は、PythonでWeb検索ツールを利用した簡易的なエージェント構築の概念コードです。

```python

from langchain_openai import ChatOpenAI

from langchain.agents import initialize_agent, AgentType

from langchain_community.tools.tavily_search import TavilySearchResults

llm = ChatOpenAI(model="gpt-4o")

tools = [TavilySearchResults()]

エージェントの初期化

agent = initialize_agent(

tools, llm, agent=AgentType.STRUCTURED_CHAT_ZERO_SHOT_REACT_DESCRIPTION,

verbose=True

)

自律実行の開始

agent.run("最新のAI市場トレンドを調査し、要約レポートを作成して")

```

このコードが示す通り、エージェントは「調査」という指示に対して、自ら検索ツールを呼び出し、得られた情報を基に要約を生成します。Cursorを利用すれば、このコードの補完からデバッグまでを一貫して高速化可能です。

業務効率化のBefore/After

導入前は、リサーチ業務に半日を費やしていたとします。検索エンジンで情報を探し、ブラウザタブを行き来し、WordやExcelに貼り付ける作業です。

導入後は、エージェントがバックグラウンドで複数のソースをクロールし、重要なインサイトのみを抽出し、ドキュメントにまとめるまでのプロセスを数分で完了させます。人間は、その「結果の検証と意思決定」に注力すれば良いのです。これこそが、AIをツールから「同僚」へと昇華させる鍵となります。

まとめ：明日から始めるロードマップ

AIエージェントの構築は、壮大なシステム開発である必要はありません。まずは以下のステップから始めてみてください。

1. **現状の定型業務を特定する**: 繰り返しが多く、情報の検索・要約が主体の作業を選びます。

2. **プロトタイピング**: LangChainやCursorを使用して、小さな単位で自動化を試みます。

3. **フィードバックループの構築**: AIの出力を人間がレビューし、推論の過程を微調整します。

AIエージェントは、業務の質を劇的に変える可能性を秘めています。技術的な背景を深く理解し、自律的なワークフローを構築することで、私たちはより創造的で価値の高い業務に集中できるようになるはずです。

ローカルLLM完全攻略：高性能モデルを自分のPCで動かすための基礎知識と導入ガイド

2026-05-05T16:16:14.784+09:00

近年、生成AIはビジネスの生産性を劇的に向上させる不可欠なツールとなりました。しかし、ChatGPTやClaudeといったクラウド型モデルの利用には、「データプライバシーの懸念」や「従量課金によるコスト増」という課題が常に付きまといます。

こうした課題を解決し、AI活用の主導権を自らの手元に取り戻す手法として注目されているのが「ローカルLLM」です。本記事では、高性能なモデルを自身のPC環境で稼働させるための基礎知識から、実践的な導入手順までを網羅的に解説します。

ローカルLLMを構築するビジネス上の意義

ローカルLLMとは、外部サーバーを介さず、自身のPC上で大規模言語モデルを動作させる技術です。なぜ今、多くのエンジニアや企業がこれを選択するのか。その理由は大きく分けて3つあります。

1. 究極のデータプライバシー確保

クラウド型AIでは、入力データが外部サーバーへ送信されます。機密情報や個人情報を扱うビジネスシーンにおいて、外部流出のリスクは避けられません。ローカルLLMであれば、通信を完全に遮断した環境（オフライン）でも動作するため、情報漏洩のリスクを極小化できます。

2. APIコストの削減と予測可能性

商用APIの利用は、トークン数に応じたコストが発生します。プロジェクトの規模が拡大するほどコスト予測は困難になります。ローカル環境であれば、初期のハードウェア投資以外、ランニングコストは実質ゼロです。APIのレート制限に縛られることもありません。

3. AIエコシステムへの適応と柔軟性

AIを単なるツールではなく、自社の業務フローに深く組み込む「エコシステム」として捉えるならば、モデルの選択肢を自ら管理できることは戦略的な優位性となります。特定のベンダーに依存しない「モデルの独立性」は、中長期的なプロジェクトにおいて不可欠な強みとなります。

ローカルLLM導入に必要なハードウェアスペック

高性能モデルを快適に動かすためには、PCのスペックが重要です。特に重要なのはGPUの「VRAM（ビデオメモリ）」容量です。

* **推奨環境**

* **GPU:** NVIDIA製GPU（RTX 3060 12GB以上を推奨）。CUDAコアを活用することで、生成速度が飛躍的に向上します。

* **メモリ（RAM）:** 16GB以上（32GB以上を強く推奨）。モデルの読み込みに大量のメインメモリを消費するためです。

* **ストレージ:** モデルファイルは数GBから数十GBに及ぶため、SSDの空き容量を十分に確保してください。

OllamaによるローカルLLM導入ステップ

現在、ローカルLLMの導入において最も効率的かつ標準的なツールが「Ollama」です。複雑な設定を排除し、コマンドライン操作だけでモデルのダウンロードから実行までを一括管理できます。

ステップ1：Ollamaのインストール

[Ollama公式ページ](https://ollama.com/)にアクセスし、自身のOSに適したインストーラーをダウンロードしてインストールを実行してください。完了後、ターミナル（WindowsであればPowerShell）を起動します。

ステップ2：モデルの選定

現在、オープンソース界隈では、Metaの「Llama 3.2」やGoogleの「Gemma 2」が圧倒的な性能を誇ります。

* **Llama 3.2:** 汎用性が高く、複雑な推論タスクに優れています。

* **Gemma 2:** Googleの最新技術を凝縮したモデルで、軽量かつ高精度な応答が可能です。

ステップ3：モデルの実行

ターミナルで以下のコマンドを入力するだけで、モデルが自動的にダウンロードされ、チャット環境が立ち上がります。

```bash

ollama run llama3.2

```

これで、ローカル環境での対話準備は完了です。インターネット接続を切り離しても、モデルは正常に動作し続けます。

次のステップ：ローカル環境を使いこなすために

導入が完了した後は、単なるチャット利用に留まらず、自身の業務へ統合させる検討が必要です。

* **Hugging Faceの活用:** [Hugging Face](https://huggingface.co/models)には無数のモデルが公開されています。専門分野に特化したファインチューニングモデルを探す際、ここが情報のハブとなります。

* **RAG（検索拡張生成）の構築:** 社内ドキュメントをベクトルデータベース化し、ローカルLLMに参照させることで、自社特有のナレッジを回答できるAIを構築可能です。LangChainなどのフレームワークを用いることで、この統合は容易になります。

まとめ：AI活用の主導権を手元に

ローカルLLMの構築は、もはや一部の研究者だけのものではありません。Ollamaの登場により、その障壁は驚くほど低くなりました。

1. **機密性の高いデータを扱う際は、ローカル環境が最適です。**

2. **GPUスペックを見極め、適切なモデルを選択することが成功の鍵です。**

3. **APIコストに縛られない環境は、持続可能なAI活用の基盤となります。**

AIを単なるツールとして消費する段階から、自らのインフラとして管理する段階へ。この移行は、企業のDXを加速させるための必然的なステップです。まずは手元のPCで、Llama 3.2の応答速度を確認することから始めてみてください。それが、次世代のビジネスインフラを構築する第一歩となるはずです。

「チャット」から「自律実行」へ：AIエージェントが変える業務プロセスの未来

2026-05-04T20:35:33.898+09:00

近年の生成AI技術の急速な進化は、ビジネスの現場にパラダイムシフトをもたらしています。これまで、ChatGPTに代表される大規模言語モデル（LLM）の主な役割は「対話を通じた情報提供」や「文章の作成」という、いわゆる「チャットAI」の領域に留まっていました。

しかし現在、AIの役割は明確にフェーズを変えています。自律的に判断し、複数のツールを操作してタスクを完遂する「AIエージェント」へと進化を遂げているのです。本記事では、AIエージェントの仕組みを紐解き、ビジネスプロセスを劇的に変える導入戦略について解説します。

「チャット」と「AIエージェント」の決定的な違い

従来のチャットAIと、次世代のAIエージェントの最も大きな違いは「自律性」と「実行力」にあります。

* **チャットAI：** ユーザーの入力に対し、最適なテキスト情報を生成して返す。あくまで「知識の検索・要約」が主目的です。

* **AIエージェント：** 目標を与えれば、達成に必要なステップを自身で立案し、APIやブラウザなどの外部ツールを操作して業務を完遂する。

AIエージェントは、LLMを「頭脳」として、実行環境と接続された「エコシステム」として機能します。例えば、「市場調査レポートを作成し、Slackで関係者に共有する」というタスクがあった場合、AIエージェントはWeb検索、ドキュメント生成、メール送信ツールを順次呼び出し、人の介在なしに業務を完了させることが可能です。

AIエージェントを支える技術要素

この自律的な動作を支えているのが、LLMを中心とした高度なアーキテクチャです。特に注目すべき技術は以下の通りです。

1. ReAct（Reasoning and Acting）

AIが思考（Reasoning）と行動（Acting）を繰り返す仕組みです。情報を検索し、その結果をもとに次の行動を論理的に判断します。LangChainなどのフレームワークでも標準的に採用されており、AIが複雑なタスクを分解して処理する能力を支えています。

2. RAG（Retrieval-Augmented Generation）

社内文書やデータベースなどの外部情報を参照させる技術です。LLMが持つ汎用的な知識だけでなく、企業の持つ固有データを正確に活用するために不可欠なプロセスです。

3. RLHF（Reinforcement Learning from Human Feedback）

人間のフィードバックを通じた強化学習です。AIの判断プロセスを人の好む方向へ最適化することで、ビジネスの現場で許容される品質とコンプライアンスを担保します。

業務効率を最大化するAIエージェント導入のロードマップ

AIエージェントを実務に導入し、成果を創出するためには、段階的なアプローチが必要です。以下の3つのステップで進めることを推奨します。

ステップ1：タスクの細分化とボトルネックの特定

まずは、現在の業務プロセスの中で「ルール化されているが手間の多いタスク」を洗い出します。AIエージェントは、定型的な手順が確立されている作業ほど高いパフォーマンスを発揮します。まずは、情報の収集、フォーマットの変換、単純なデータ入力作業から自動化の対象を絞り込みます。

ステップ2：限定的な環境での「人間による監視」

AIエージェントを完全に自律させる前に、人間の承認ステップ（Human-in-the-loop）を組み込みます。重要な意思決定や外部への情報送信については、AIの提案を確認し、人がクリックするだけで実行される仕組みから構築を開始します。これにより、リスクを制御しつつAIの能力を検証します。

ステップ3：自動学習と継続的な最適化

運用を通じてAIのログを蓄積し、パフォーマンスを分析します。特定のケースで失敗が多い場合は、プロンプトの調整や、RAGに用いる社内ナレッジの更新を行うことで、精度を継続的に向上させます。「AIを育てていく」という意識を持つことが、導入成功の鍵となります。

まとめ：AIをツールではなくパートナーとして捉える

AIエージェントの導入は、単なるコスト削減のための自動化ではありません。それは、AIを「ツール」から「自律的に働くビジネスパートナー」へと転換させるプロセスです。

今後、ビジネスの競争優位性は、いかにAIエージェントを組織のワークフローに統合できるか、そしてAIの学習サイクルを自社の中に構築できるかにかかっています。OpenAIやHugging Faceなどで公開されている最新のフレームワークを積極的に調査し、まずは小規模なパイロットプロジェクトから着手することが、未来の働き方を勝ち取るための第一歩となります。

今、私たちが問われているのは「AIに何をさせるか」ではありません。「AIが自律的に動く環境をどう設計するか」という戦略的な視点です。この変化を機会と捉え、自社のビジネスプロセスを再構築していくことが、今後の企業成長に不可欠であると確信しています。

【チャットボット】チャットボットの仕組みの技術資料

2020-12-14T22:04:00.004+09:00

Webサイトで見かけることが多くなったチャットですが、中に人がいて人が対応してくれるもの、ボットが無人で対応してくれるものなどがあります。

ボットが無人対応するものはどんな仕組みになっているのか？どのボットも質問をすると何か返してくれるという動きは同じですが中の仕組みは色々とあるようです。そのような参考記事はこちら。

【チャットボット – その種類別の仕組み】

仕事などでチャットボット製品の調査をするときに、このような仕組みからベンダに質問できると、より自分たちに合ったものを選べそうですね。

種別ごとの詳細もありますので、参考にしてみてください。

以上

【チャットボット】 SharePointと連携して社内チャットを便利に活用

2020-12-07T13:25:00.006+09:00

企業内でのコミュニケーションにMicrosoft TeamsやGoogle Chatなどの企業向けチャットをを使ってますという話を聞く機会も、最近多くなって来たように感じます。リモートワークに合わせて企業向けチャットを社内コミュニケーションに使い始めたという会社も多いのだろうなと思います。

リモートワークといえばワードやパワーポイントのなどファイルサーバーにあるものを「あれどこにあるっけ？」と場所を教えてもらっていたものが、それがやりにくくなったのがちょっと困ったことです。チャットで聞いたりしていますが、全体のグループで聞くのも気が引けるしなど、誰にどう聞こうか一瞬迷ってしまいます。

こんな場合に役に立ちそうなツールのβ版がリリースされたとのことなので紹介します。チャット経由で「○○のファイル」という感じで質問するとSharePointの中に格納されているファイルを探してくれるそうです。 SharePointの通常の検索だとファイル名やキーワードが正確にわからずに探すのにはいつも苦労するのですが、このツールはファイル名が曖昧であっても近しいものを抽出して候補を表示することで、目的のファイルをチャットボットが探してくれるようです。

【「ENOKI5.0 SharePoint連携オプション」のβ版】

今ならβ版ということでトライアルができるようなので、Microsoft365やSharePointでファイル管理されている方は試してみてはいかがでしょうか？

【チャットボット】無料トライアルの落とし穴

2020-11-30T18:30:00.000+09:00

チャットボットの導入検討の際にトライアルをしてみるのはとても有効だと思います。最近は無料トライアルができる製品も増えてきました。導入するのにどんなデータが必要なのか？運用するのにメンテナンス性はどうなのかは検討しておきたいですよね。

トライアルをする場合の注意点がこちらの記事にありますので、ぜひ参考にして下さい。こういうのは実際やってみないと、なかなか気がつかないことかと思いますが、知っているかどうかでも評価にだいぶ差が出てきますね！

【チャットボット – 無料トライアルの落とし穴】

トライアルを考えている方の参考になれば幸いです！

【チャットボット】目的に合ったチャットボットを選ぶ

2020-11-26T09:41:00.004+09:00

チャットボットを設置したサイトが最近多くなってきて、チャットボット製品も色々なものが数多く出ています。見た目は同じなのでちょっと調査しただけでは違いがわかりにくくどれを選んでも同じに見えますが、用途や状況によって選ぶポイントがあるという記事を紹介します。

【お客様にマッチしたチャットボットを選ぶには？～チャットボットマッチングチャート～】

上記のチャートでは以下のような区分けで、有人対応／無人対応どちらにするか、無人対応するならどの方式がいいか説明していますので参考にしてもらえればと思います。

有人チャット
無人チャット

シナリオ型チャット
機械学習型チャット
ハイブリッド型チャット

以上、チャットボットの選び方についてのご紹介でした。

MyBatisでヘッダ明細型のデータをINSERTする（自動採番もする）

2020-06-14T09:45:00.002+09:00

MyBatisでヘッダ明細型のデータを扱うシリーズの3回目。今回はネストしたJavaオブジェクトをデータベースに新規作成する方法について書いてみたいと思う。またIDもデータベースで自動採番させようとちょっと欲張ったものにしている。今回はSQLの都合上MySQLに特化した内容となっている。

今回のサンプルもいつもと同じ以下のクラスとテーブルを使用する。

public class Student {
  int id;
  String name;
  Result[] result;
}

public class Result {
  String course;
  int score;
}

studentテーブル(ヘッダ)

id	name
100	やまだ

resultテーブル(明細)

refid	course	score
100	英語	80
100	数学	90

データベースはMySQLを使用する。 idは連番を振りたいのでデータベースで自動採番させてしまおう、ということで以下のようにテーブル定義をした。

CREATE TABLE student (
  id INTEGER NOT NULL AUTO_INCREMENT UNIQUE,
  name VARCHAR(100)
);

CREATE TABLE result (
  refid INTEGER NOT NULL,
  course VARCHAR(100),
  score INTEGER
);

MyBatisのmapper定義

さて、ヘッダ明細型のテーブルに対してJavaオブジェクトをINSERTするMyBatisのmapperの定義をする。 INSERTの処理としてまず思いつくのは、MyBatisの設定でstudentテーブルとresultテーブルにINSERTするmapperをそれぞれ作成してJavaコードから順に呼び出す方法だろう。この場合はStudentクラスのオブジェクトをMyBatis経由で書き込んだ後、resultの配列ごとにループを回してResultクラスのオブジェクトをMyBatis経由で書き込む処理となる。

しかし、ネストしたStudentクラスのオブジェクトをMyBatisに渡して、その中でネストした部分も書き込んでもらうことはできないだろうかということで、以下のようなmapperを作成した。

<mapper namespace="mapper.student">
  <resultmap id="student" type="student">
    <id column="id" property="id" />
    <result column="name" property="name" />

    <collection property="result" oftype="Result">
      <result column="course" property="course" />
      <result column="score" property="score" />
    </collection>
  </resultmap>

  <insert id="create" parameterType="student" useGeneratedKeys="true" keyProperty="id">
    INSERT INTO student (name) VALUES (#{name});
    SET @uid = LAST_INSERT_ID();
    <if test="result != null">
      <foreach item="i" collection="result">
        INSERT INTO result (refid, course, source)
          VALUES (@uid, #{i.course}, #{i.source});
      </foreach>
    </if>
    SELECT @uid FROM dual;
  </insert>

</mapper>

まずは最初の "INSERT INTO student ～" でStudentクラスのオブジェクトをstudentテーブルに書き込む。

次の行で "SET @uid = LAST_INSERT_ID()" を行っているが、ここでstudentテーブルに書き込んで自動採番されたIDを取得している。これはMySQL専用の構文となる。

次にMyBatisの動的SQLを使ってネストしたオブジェクトを1つづつINSERTする。
まず、<if test="result != null"> でStudentクラスのオブジェクトがネストしたResultオブジェクトを持っているか（nullでないか）を調べ、持っているなら <foreach item="i" collection="result"> でひとつづつ順にINSERT処理をしている。
resultテーブルではrefid列に紐づくstudentテーブルのidを保持するが、先にMySQLの変数 "@uid" に自動採番された値を保存しているので、その値を書き込んでいる。

自動採番された値はJavaのStudentクラスのオブジェクトにも反映したい。MyBatisの処理結果として返した値が反映されるので、最後に "SELECT @uid FROM dual" を実行して、自動採番された値を返している。

Javaコードから書き込み

以下のようなJavaコードでネストされたオブジェクトを1回のMyBatis呼び出しでヘッダ明細型のテーブルにINSERTできる。

// 英語の結果
Result result_english = new Result();
result_english.course = "英語";
result_english.score = 50;

// 英語の結果
Result result_math = new Result();
result_math.course = "数学";
result_math.score = 68;

// 生徒の情報
// IDは自動採番されるため
Student student = new Student();
student.name = "たなか";
student.result = new Result[] { result_english, result_math };

// オブジェクトをデータベースに書き込む
sqlSession.insert("mapper.student.create", student);

// 自動採番された生徒のIDを表示
System.out.println("ID=" + student.id);

おわりに：BadSqlGrammarExceptionが出た時

Springから使っていたらこんな例外が出てしまいました。

org.springframework.jdbc.BadSqlGrammarException: 
### Error updating database.  Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'SET @uid = LAST_INSERT_ID();
		 
		SELECT @uid FROM dual' at line 3

今回はMyBatisのmapperで複数のステートメントを一度に実行していますが、MySQLのJDBCドライバの仕様で複数ステートメントを実行するときは "allowMultiQueries=true" オプションを指定する必要があるようです。JDBC接続のURLに以下のようにオプションを追加したらうまく動くようになりました。


jdbc.url=jdbc:mysql://localhost/student?allowMultiQueries=true

JavaのSimpleDateFormatで日付文字列チェックではまる

2020-05-26T13:51:00.001+09:00

java.text.SimpleDateFormatを使って日付文字列をチェックしようとしてはまったときのメモ。 parseメソッドに文字列を与えてParseExceptionが出るか出ないかでチェックしようとした。

SimpleDateFormat fmt = new SimpleDateFormat("yyyyMMdd");

// 不正な日付
Date d = fmt.parse("197405112"); // ParseExceptionが発生しない！！

しかし、エラーとはならず、yyyy=1970、MM=05、dd=112と解釈され、5月112日→8月20日として、d=1974/8/20として通ってしまい予想外の動きになってしまった。 SimpleDateFormatはデフォルトだとできるだけ日付として解釈するように動作をするらしい。日付を３桁で拾ってしまうのは予想外だったが・・・

存在しない日付を厳密にチェックするときはsetLenientをfalseに設定する必要があるようだ。以下にすることでチェックをすることができた。

SimpleDateFormat fmt = new SimpleDateFormat("yyyyMMdd");

// 厳密な日付チェックを行う設定
fmt.setLenient(false);

// 不正な日付
Date d = fmt.parse("197405112"); // ParseException発生！！

SimpleDateFormatはスレッドセーフではなく使いまわしが難しいので、そろそろ新しいスレッドセーフなDateTimeFormatterに移行するべきとは思うが、Dateを使っている手持ちライブラリも多く使い勝手の悪さからなかなか移行できていない・・・

MySQLでUnknown command '\''.がでる。

2020-05-15T18:25:00.001+09:00

MySQL5.7でSQLを流した時にUnknown command '\''.がでる時の対処法。

どういう状況で出るのかはいまいちはっきりしていないが、UTF-8のファイルを流した時に出る？ 5.6などでは同じSQLでも出ていなかったように思われる。このようなときは--default-character-set=utf8オプションを指定してやると成功するようだ。

mysql -umydb -pmypass -Dmydb --default-character-set=utf8 < data.sql

MyBatisでヘッダ明細型のデータを扱う（行範囲を指定）

2020-05-12T22:01:00.001+09:00

前回の記事でヘッダ明細型のデータをMyBatisで読み込む方法としてcollectionタグを使いネストしたJavaオブジェクトに読み込む方法を紹介した。ヘッダテーブルと明細テーブルを結合した1つのSQLで読み込みができるため楽な方法ではあるが使い方に癖があるようなので注意しないと思わぬところではまってしまう。その一つが行数を指定して読み込むときである。

例として以下のようなデータをcollectionタグを使いネストしたJavaオブジェクトで読み込んでみよう。

studentテーブル(ヘッダ)

id	name
100	やまだ
101	たなか
102	おばた
103	ささおか

resultテーブル(明細)

refid	course	score
100	英語	80
100	数学	90
101	英語	50
101	数学	68
102	英語	77
102	数学	70
103	英語	98
103	数学	92

読み込むオブジェクトのJavaクラスの定義とMyBasisのmapperは前回の記事と同じものを使用する。

Javaクラス定義

public class Student {
  int id;
  String name;
  Result[] result;
}

public class Result {
  String course;
  int score;
}

MyBasisのmapper定義

<mapper namespace="mapper.student">
  <resultmap id="student" type="student">
    <id column="id" property="id" />
    <result column="name" property="name" />

    <collection property="result" oftype="Result">
      <result column="course" property="course" />
      <result column="score" property="score" />
    </collection>
  </resultmap>

  <select id="find" resultmap="student">
    SELECT id, name, course, score
    FROM student, result
    WHERE id = refid
    ORDER BY id
  </select>
</mapper>

IDの小さい順に2人、やまだ君(100)、たなか君(101)、のデータだけ読み込むことを考えてみる。MyBatisではRowBoundsを使うことで指定した行範囲のデータを読み込むことができるので、以下のコードで0行目から2行の読み込みをしようとした。

// 読み込む行範囲を指定、先頭から2行のデータを読み込む
int offset = 0;
int limit = 2;
RowBounds rowBounds = new RowBounds(offset, limit);

// SQLに渡すパラメータ（特に無し）
Map<String,Object> params = new HashMap();

// SQLを発行してオブジェクトにマッピングする
List<Student> students = sqlSession.selectList("mapper.student.find", params, rowBounds);

しかしcollectionを使っている場合はそんなに単純ではない。RowBoundsへの期待はstudentテーブルの先頭2行だけであるが、SELECTの結果は以下のようにstudentの内容とresultの内容が1行に結合されたものとなり、RowBoundsはその先頭2行を対象としてしまうようである。結果的にstudentsには、やまだ君のデータだけが読み込まれる。

SELECTの結果

id	name	course	score	RowBoundで選ばれる行
100	やまだ	英語	80	〇
100	やまだ	数学	90	〇
101	たなか	英語	50	×
101	たなか	数学	68	×
102	おばた	英語	77	×
102	おばた	数学	70	×
103	ささおか	英語	98	×
103	ささおか	数学	92	×

これを回避するにはRowBoundsを使わず、全行読み込んだ後にoffsetとlimitでリストを切り取る処理を行っている。一旦全行読み込んで処理をするのでメモリ的にもCPU的にも負荷がかかるのが欠点ではあるが、それほどの規模でなければコードの読みやすさでこの方法を使っている。ただ、行数が多いテーブルではSQLの書き方も工夫するなど何らかの対策が必要がと思われる。

// 読み込む行範囲を指定、先頭から2行のデータを読み込む
int offset = 0;
int limit = 2;

// SQLを発行してオブジェクトにマッピングする
List<Student> students = sqlSession.selectList("mapper.student.find");

// 行範囲で切り取り
int s = offset;
int e = offset+limit;
if (s < 0) { s = 0; }
if (e >= students.size()) { e = students.size(); }
if (s == 0 && e >= students.size()) {
	return students;
} else {
	return students.subList(s, e);
}

MyBatisでヘッダ明細型のデータを扱う

2020-04-29T21:28:00.051+09:00

「ヘッダ明細型」のデータはアプリを作るうえでよく登場するデータ構造である。「ヘッダ」が親データ、「明細」が親に紐づく子データを表しており、例えば成績のデータなどで、各生徒の英語と数学の成績を表す場合に生徒の情報を親としてヘッダテーブルに格納、成績情報は親にidで紐づけて明細テーブルに格納すると以下のようにあらわすことができる。

studentテーブル(ヘッダ)

id	name
100	やまだ
101	たなか

resultテーブル(明細)

refid	course	score
100	英語	80
100	数学	90
101	英語	50
101	数学	68

やまだ君の成績は英語80点で数学90点。たなか君の成績は英語50点で数学68点を表している・・・たなか君はもう少し頑張ったほうがいいですね・・・

このようなデータの持ち方は「Summary」と「Detail」などとも呼ばれたり、呼び方はさまざまであるが、商品カートや伝票など業務の世界でも頻繁に登場する。

このようなデータを扱う場合はStudentクラスがResultクラスのオブジェクトを持つようなネストした構造で表現することができる。例えばJavaの場合のクラス定義は以下のようになる。setter/getterメソッドは省略して書いているので適宜付与してもらうとよいだろう。

public class Student {
  int id;
  String name;
  Result[] result;
}

public class Result {
  String course;
  int score;
}

ここでMyBatisを使ってstudentテーブルとresultテーブルの内容を上記クラスに読み込むことを考えてみる。studentテーブルをSELECTしてからresultテーブルをSELECTするように2つのSELECTに分けてもよいが、MyBatisではテーブルを結合した1つのSQLでネストしたクラスを読み込むことができる。

mapperでcollectionタグを使いネストした部分を定義する。property属性に子オブジェクトを格納するプロパティ名、oftype属性にそのクラス名を指定する。 SELECTのSQLでは2つのテーブルを結合する。

<mapper namespace="mapper.student">
  <resultmap id="student" type="student">
    <id column="id" property="id" />
    <result column="name" property="name" />

    <collection property="result" oftype="Result">
      <result column="course" property="course" />
      <result column="score" property="score" />
    </collection>
  </resultmap>

  <select id="find" resultmap="student">
    SELECT id, name, course, score
    FROM student, result
    WHERE id = refid
    ORDER BY id
  </select>
</mapper>

SELECTの結果は以下のようにstudentの内容とresultの内容が1行に結合されたものとなるが、親クラスの内容はmapperのidタグで指定された列でまとめられオブジェクトが構築されるようである。

SELECTの結果

id	name	course	score
100	やまだ	英語	80
100	やまだ	数学	90
101	たなか	英語	50
101	たなか	数学	68

以下のコードで読み込みを行うと・・・

List<Student> entities = sqlSession.selectList("mapper.student.find");

下図のようなオブジェクトとして読み込まれる。

使いこなせば複雑なデータ構造をシンプルに扱えそうな方法であるが、実際使ってみると気を付けなければならない点もあり、そのような点は次回以降また紹介していこうと思う。

機械学習と深層学習

2020-04-23T21:23:00.001+09:00

「機械学習と深層学習って何が違うの」という質問を受けることが良くあるが、その説明としてこの図がわかりやすいのかなと思う。

「機械学習」というのは、何らかのパターンを自動で覚えて、次に何らかのパターンが発生したときに、過去に覚えたパターンと近いかどうかを判別したり、次にどういうパターンになるかを予測するようなプログラムのこと。
パターンというのは、例えば画像だったり、文字列だったり、株価の毎日の変動だったり。例えば、犬の画像をたくさん覚えた機械学習に動物の写真を入力すると犬かどうか判別したりできるし、株価のデータを入力すると次の日に上がるか下がるかを過去のパターンから予測してくれるようになる。自動で覚えてとは書いたが人がそれらのデータを集めて機械学習のプログラムに覚えさせてもいいと思う。

一方で「深層学習」とは「ディープラーニング」や「ディープニューラルネットワーク(DNN)」とも呼ばれるが、機械学習をするための一つの手法のこと。これのベースになっている「ニューラルネット」という技術は神経細胞に似た網目構造を使って計算する方式で何十年も前から知られていて、網目構造を増やす（層を深くする）と性能が上がることはわかっていた。しかし昔はコンピューターが非力だったので少し増やすと計算が終わらず使い物にならなかったのが、最近はまともに動くようになってきて性能も高く実用的になったので一気に知名度が上がってきたというものである。

ただ、深層学習は一気に知名度が上がったので、世の中的には機械学習＝深層学習と見てしまわれることが多い。そんな感じで冒頭の質問をされた時には、ちょっと古いが、ヘッドホンステレオ＝ウォークマンと同じイメージと説明している。

深層学習の中にも層の作り方やデータの処理の仕方でいろいろな方法があって、画像判定が得意とか、予測が得意とか、用途に応じて使い分けられている。例えば、最後に紹介するDEEPという深層学習では文章を解析して分類することができるものとなっていて、ここの研究論文にあるような飲食店のレビュー文章を分析することをしている。

Kumasoftの開発記録

【COLLEAGUE.SKILL入門】退職した同僚の「仕事の進め方」と「人柄」をAIに蒸留する実践セットアップガイド

暗黙知と人柄を切り離す「二層構造（Dual Representation）」

1. 能力（Capability）トラック：work.md

2. 振る舞い（Behavior）トラック：persona.md

導入手順：主要エージェントへのワンコマンドインストール

ステップ1：データソースの準備

ステップ2：エージェント環境へのインストール

ステップ3：初期設定ファイルの作成

よくあるエラーと対処法：対話を通じた継続的修正

エラー1：判断基準が実際の業務と異なる場合

エラー2：口調や振る舞いが不自然な場合

エラー3：不適切なプライバシー情報の露出

結論

MCP Appsの基本構造：Resources・Prompts・Toolsの役割分担からマルチエージェント、Smitheryへの展望

LLM外部連携における「密結合」の限界とMCPの登場

3つの基本機能：Resources・Prompts・Toolsの設計思想

Resources：安全性が担保された読み取り専用データ

Prompts：定型的なコンテキスト生成と制御の分離

Tools：副作用を伴うアクションの実行

実装コードから学ぶMCPの構造

マルチエージェントとパッケージ管理「Smithery」が拓く未来

テクノロジーをシステムとして統合する

ビジネスを加速するdocling活用ガイド：何ができるかと実践導入手順

1. 現状の課題：LLM時代に立ちはだかる「ドキュメント前処理」の壁

2. 解決策：doclingがもたらすビジネス価値と技術的優位性

3. doclingの実践導入手順とコード例

3.1 環境構築

3.2 基本的なMarkdown変換の実装

3.3 複雑な「表データ」の正確な抽出

4. 導入時における典型的なエラーと回避策

4.1 依存ライブラリの不足によるコンパイルエラー

4.2 メモリ不足（OOM: Out of Memory）による強制終了

5. 実務適用に向けたビジネスロードマップ

RAGとLoRAの使い分け：LLMの知識拡張と個別最適化のアーキテクチャ

はじめに：LLMの知識拡張における二つの選択肢

RAG：外部データベースを「脳の外部メモリ」にする

なぜRAGを選ぶのか

LangChainを用いた実装の勘所

LoRA：モデルの「話し方」と「振る舞い」を個別最適化

LoRAの技術的背景

使い分けの基準

どちらを選ぶべきか：設計の意思決定

FastMCPで学ぶ：AIエージェントに自作ツールを実装する最短ルート

AIエージェントの拡張性を左右する「MCP」という選択肢

FastMCPによるツール実装のメカニズム

シンプルな計算ツールによる実装例

メタデータが精度を高める理由

Claude Desktopへの統合設定

次世代AIエージェント基盤：ローカルLLMとMCPを融合させた高セキュリティ環境の構築

はじめに：クラウド依存からの脱却とローカル環境の再定義

1. なぜ「ローカルLLM × MCP」なのか

2. アーキテクチャの設計思想とトレードオフ

3. 実践：ローカル環境構築のステップ

手順1：Ollamaの起動

手順2：MCPサーバーの定義（Python例）

4. セキュリティとガバナンスの観点

今後の展望

実用レベルへ引き上げる！カスタムスキル開発の基礎と設計パターン

AIエージェントを「実用」へと引き上げるカスタムスキルの重要性

カスタムスキルとは何か：エージェントの拡張機能

カスタムスキル設計の基本パターン

1. 情報参照型（Read-Only）

2. アクション実行型（Write/Execute）

3. データ加工・集計型（Transformer）

Pythonによるカスタムスキルの実装例

実用レベルへ引き上げるための3ステップ

結論：エージェントはツールではなく「エコシステム」である

AIエージェントの「スキル」とは？仕組みから実装の基本までを完全網羅

はじめに

AIエージェントにおける「スキル」とは

スキル実行のメカニズム

LangChainによる実装の基本ステップ

1. ツールの定義

2. LLMのバインドとエージェント構築

3. 実行

実装における注意点

まとめ

AIエージェントの「手足」を作る：スキル実装の基礎と仕組みを完全網羅

はじめに

1. 能力（Capability）トラック：`work.md`

2. 振る舞い（Behavior）トラック：`persona.md`

【チャットボット】無料トライアルの落とし穴