2
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@gyunyu_daisuki(海渡 山下)in株式会社インプリム

PleasanterにAIエージェントを活用したアプリを実装しよう【Gemini】

2
Last updated at Posted at 2026-03-30

はじめに

Pleasanterはある程度使えるようになってきて、業務アプリもいくつか作ってきたけどもう少し発展して便利なアプリが作れたらいいのにな～
そう考えたことはありませんか？

2026年3月のバージョンアップにて、Pleasanterには待望のMCPサーバーが実装されました。
▶Pleasanter MCPを使う
これにより特定のサイトからレコードを取得して分析を行ったり、レコードの更新をしたり、、、皆様がお使いのPleasanterに沿った優秀なAIエージェントとして運用ができるようになりました。
正直めちゃ便利です。私はマルチタスクが苦手なので、タスクをそれぞれレコードに登録し、Geminiを通してどう進めていくべきか分析─────的な使い方をしています。

確かにこういった使い方も便利なんですが、『レコードを登録したらAIがよしなに処理してくれるアプリが欲しいな』と思ったことはないですか？
私は思いました。
というわけで、今回はMCPサーバーではなく、PleasanterとAIエージェントを連携したアプリを開発していきます。

なにを作るか

AI連携をするに当たってPleasanter上に実装しなければならないものは以下の３つです。

  • 命令を渡すための入力項目
  • AIによって出力される結果を入れる項目
  • プロンプト(Pleasanter上に実装しなくても良いが、あったほうが分かりやすい)

AIと連携するアプリケーション作成は難しいイメージがありますが、これらが準備できればあとはこの内容をAPIで飛ばしてあげればAIエージェントが回答してくれます。
事前にいくつか作ってみましたが、同じフォーマットが使い回せるため、項目名とプロンプトを書き換えるだけで１～２時間で複数のアプリケーションを作成できました。

今回は議事録作成アプリを作成しましょう。
{D06310F5-3EFD-48AC-9751-732EC1E1921E}.png

事前準備

Pleasanter

ローカルに準備したものを使用します。
バージョン：1.5.2.0
DB：Postgres17
DockerComposeを利用して構築しています。

Gemini

今回使用するモデルはGemini 3.1 Flash Liteです。
Gemini 3.1 Flash Liteは無料枠でも使用できるモデルの中では最高の性能を誇っており、1日あたり最大500リクエスト(1分間最大15リクエスト)、トークンは1分あたり20万文字程度読み込ませることが可能です。
{FC6EF98E-24ED-47CE-91A7-0A7B4AAF3A6C}.png
GeminiのAPIを使用可能にするため、GoogleAIStudioへアクセスし、プロジェクトの作成とAPIキーの発行を行っておきます。
{AFC8EBD6-0233-4854-86FA-4BCB532FDECC}.png

アプリの作成

APIキーの準備ができたら、Pleasanterにアプリを作成します。
視認性も重視したいので、各部を以下の見出しで分割します。

使用する項目

  • プロンプト(折りたたみ可/デフォルト:閉じる)
    • 説明A(読み取り専用)
      →ベースとなるプロンプトを既定値に設定
  • 入力項目(折りたたみ可/デフォルト:開く)
    • 説明B
      →トランスクリプトを貼り付ける項目
    • 分類B
      →補足として固有名詞などを指定する項目
    • 分類A
      →議事録形式(アジェンダ、会議の内容、決議事項、Todoリストなどを必要に応じて作成可能)
  • 出力結果(折りたたみ不可)
    • 説明C
      →読み取り専用でAIエージェントによって出力された結果を格納

プロンプトの基本文法について

AIエージェントに命令文を投げるとき、ただ自然言語で命令するのもある程度のクオリティが返却されますが、AIにはAIの理解しやすい書き方があります。
これを基本文法といいます。
基本文法は以下の3つ＋αで構成されます。

  1. 命令
  2. 条件
  3. 回答形式

例えば

説明B項目の依頼内容をもとに、詳細な議事録を作成してください。

と依頼をするより、

#命令
以下の情報は会議の文字起こしデータです。
#出力形式の内容に忠実に従って、マークダウン形式で内容の抜け漏れやずれの無いよう、詳細かつ論理的でMECEな議事録を作成してください。
出力時は1行目に[md]を出力してください。
#補足は固有名詞や間違えやすい単語がカンマ区切りで入力してあります。#補足に入力された内容があれば1単語として扱ってください。

#出力形式
{議事録形式} をそれぞれH2見出しでまとめる。

#文字起こしデータ
{会議音声の文字起こし}

#補足
{補足内容}

とすることでAI的には「ふむ、#命令 が依頼内容なんだな。出力は #出力形式 に則ればいいんだな。 #文字起こしデータ を議事録にすればいいんだな」と理解しやすくなります。

サーバスクリプト

AIエージェントとの連携はサーバスクリプトを使用します。
説明Aに既定値として入っているベースのプロンプトに対し、入力項目に入力した内容で書き換えを行います。
完成したプロンプトをAPI経由でAIエージェントに投げて、出力された結果を説明Cに格納します。

// プロンプトの組み立て
let promptTemplate = model.DescriptionA;
let prompt = promptTemplate
    .replace('{会議音声の文字起こし}', model.DescriptionB)
    .replace('{補足内容}', model.ClassB)
    .replace('{議事録形式}', model.ClassA);  
let apiKey = '｛事前に作成したGeminiのAPIキーを入力｝'; 
let url = 'https://generativelanguage.googleapis.com/v1beta/models/gemini-3.1-flash-lite-preview:generateContent?key=' + apiKey;
// ペイロードの作成
let payload = {
    contents: [{
        parts: [{
            text: prompt
        }]
    }]
};

// HTTPリクエスト
httpClient.RequestUri = url;
httpClient.Content = JSON.stringify(payload);
let response = httpClient.Post();
if (httpClient.IsSuccess) { 
let json = JSON.parse(response);
    if (json.candidates && json.candidates.length > 0) {
        model.DescriptionC = json.candidates[0].content.parts[0].text;
    } else {
        model.DescriptionC = "翻訳に失敗しました。レスポンス形式が想定と異なります。\n" + response;
        context.Log(response);
    }
} else {
    model.DescriptionC = "通信エラーが発生しました。ステータスコード: " + httpClient.StatusCode + "\nエラー内容:\n" + response;
    context.Log(response);
}

作成したアプリをテストしてみる

ここまでの手順で、無事議事録作成アプリが完成しました。
では実際に動かしていきます。
実際のトランスクリプトを使うわけにはいかないので、今回はトランスクリプトもAIに作成してもらいました。

以下の文章を貼り付け、実際に議事録を作成してもらいます。 
架空トランスクリプト：社内業務システム刷新プロジェクト キックオフ

00:00 田中 (PM)
定刻になりましたので、只今より「社内業務システム刷新プロジェクト」のキックオフミーティングを開始いたします。皆様、本日はお忙しい中お集まりいただきありがとうございます。本日の進行と、本プロジェクトのプロジェクトマネージャーを務めさせていただきます、情報システム部の田中です。よろしくお願いいたします。

00:25 鈴木 (営業部)
営業部の鈴木です。ユーザー部門の代表として参加します。本日はよろしくお願いいたします。

00:32 佐藤 (開発リード)
情報システム部の佐藤です。技術面のリードと、インフラ周りの構築を担当します。よろしくお願いします。

00:40 高橋 (総務部)
総務部の高橋です。鈴木さんと同じく、現場のユーザー側の意見を取りまとめる役割として参加させていただきます。よろしくお願いします。

00:51 田中 (PM)
ありがとうございます。それでは早速ですが、事前に配布しております資料を画面に投影いたします。……はい、見えておりますでしょうか？

01:05 鈴木 (営業部)
はい、見えています。

01:08 田中 (PM)
ありがとうございます。本日のアジェンダは大きく4点です。1点目が「プロジェクトの背景と目的」、2点目が「全体スケジュール」、3点目が「役割分担と体制」、そして最後に「質疑応答と次回のお打ち合わせについて」となります。
まず1点目ですが、現在利用している社内のワークフローシステムが来年3月でサポート切れとなるため、より柔軟にカスタマイズ可能な新しいプラットフォームへ移行するのが本プロジェクトの最大の目的です。また、リモートワークでの承認作業の遅延など、現在挙がっている課題を解決し、ペーパーレス化をさらに推進していきたいと考えております。ここまでで何かご質問はございますか？

02:30 高橋 (総務部)
総務部の高橋です。ペーパーレス化の推進についてですが、現在紙で回覧している「備品購入申請」や「慶弔届」なども、今回の新システムで完全に電子化されるという認識で間違いないでしょうか。

02:48 田中 (PM)
はい、そのご認識で間違いありません。第一フェーズでは、社内で利用頻度の高いトップ10の申請フォームを優先的に電子化し、その後順次拡大していく計画となっております。

03:05 高橋 (総務部)
承知いたしました。ありがとうございます。

03:10 田中 (PM)
続きまして、2点目の全体スケジュールについてご説明します。資料の4ページ目をご覧ください。
本日から約1ヶ月半、5月末までを「要件定義フェーズ」とします。ここで現在の業務フローの洗い出しと、新しいシステムでの運用ルールを決定します。その後、6月から7月にかけて「設計・開発フェーズ」、8月に「ユーザーテスト」、そして9月1日の本稼働を目指すスケジュールとなります。

04:00 鈴木 (営業部)
営業部の鈴木です。スケジュールの件で1点質問させてください。8月に「ユーザーテスト」とありますが、我々営業部のメンバーも実際にシステムを触ってテストをする時間を確保する必要があるかと思います。月末は営業成績の締め作業があり、現場のリソース確保が難しいのですが、テストの実施時期はいつ頃を予定していますか？

04:28 佐藤 (開発リード)
技術担当の佐藤から回答いたします。ユーザーテスト（UAT）につきましては、8月の第2週から第3週、お盆明けの期間を中心に行う予定です。月末の繁忙期には重ならないようにスケジュールを組んでおります。テストにかかる工数としては、各部門2名程度の方に、1日あたり1〜2時間程度ご協力いただく想定です。

05:01 鈴木 (営業部)
なるほど、その時期であればメンバーの調整も可能です。承知いたしました。ご配慮ありがとうございます。

05:12 田中 (PM)
ありがとうございます。続いて3点目、体制と役割分担についてです。私、田中が全体の進行と課題管理を行い、佐藤が実際のシステム構築とデータ移行を行います。鈴木様と高橋様には、各部門の要件取りまとめ、現行フローの共有、そして先ほど出たテストのご協力をお願いいたします。
それでは、全体を通して何かご不安な点や確認しておきたい事項はございますでしょうか。

06:30 高橋 (総務部)
総務部の高橋です。現行システムに入っている過去の申請データについてですが、これはすべて新しいシステムに移行されるのでしょうか？過去のデータが消えてしまうと、監査の際に困るのですが。

06:50 佐藤 (開発リード)
佐藤です。データの移行方針についてですが、基本的には「過去3年分」のデータを新システムへ移行する計画で進めたいと考えております。それ以前の古いデータにつきましては、CSVやPDFの形でアーカイブ化し、参照専用の別サーバーに保管するという代替案を提案させていただきます。全件を新システムに載せ替えると、移行コストや開発期間が大幅に膨らんでしまうためです。

07:35 高橋 (総務部)
なるほど、コストの兼ね合いですね。過去のデータを日常的に見る頻度はそこまで高くないので、アーカイブで検索ができれば実務上は問題ないかと思います。念のため、部内でもその方針で問題ないか、上長に確認しておきます。

08:00 田中 (PM)
ありがとうございます。では、高橋さんの宿題事項として「過去データのアーカイブ方針についての部内合意を取る」という点を、本日のアクションアイテムとして議事録に残しておきますね。
他に何かございますでしょうか。

08:20 鈴木 (営業部)
鈴木です。私からは特にありません。

08:25 田中 (PM)
それでは最後に、今後の定例会について決定したいと思います。要件定義フェーズ中は、週に1回、1時間程度の定例ミーティングを設けたいと考えております。皆様、来週以降、毎週水曜日の14時から1時間は確保可能でしょうか？

09:00 鈴木 (営業部)
私は水曜14時で問題ありません。

09:05 佐藤 (開発リード)
私も空いています。

09:10 高橋 (総務部)
すみません、水曜の14時は毎週総務部の定例会議が入っておりまして……。15時からであれば参加可能なのですが、いかがでしょうか。

09:25 田中 (PM)
承知いたしました。では15時からに変更しましょう。佐藤さん、鈴木さん、水曜15時からはいかがですか？

09:35 鈴木 (営業部)
はい、大丈夫です。

09:38 佐藤 (開発リード)
問題ありません。

09:40 田中 (PM)
ありがとうございます。では、今後の定例会は「毎週水曜日の15時から16時」で設定させていただきます。後ほど皆様の予定表に招待をお送りいたします。
次回の定例会では、営業部および総務部の現在の業務フローのヒアリングを行いたいと思います。鈴木様、高橋様は、事前に現場での課題感や、新しいシステムで実現したいことなどを箇条書きで構いませんので、まとめておいていただけますと幸いです。

10:30 鈴木・高橋
承知いたしました。

10:35 田中 (PM)
それでは、予定より少し早いですが、本日のキックオフミーティングは以上で終了となります。今後のプロジェクト進行、どうぞよろしくお願いいたします。本日はありがとうございました。

10:50 全員
ありがとうございました。失礼いたします。

出力結果

出力結果は以下のようになりました。
生成までにかかった時間は20秒ほどです。
{46B6D76D-094A-4695-BCF9-5A19AE5A4C3C}.png

もちろんAIエージェントによる作成なので同じ文章を投げても全く同じ結果が返ってくるというわけではなく、毎回少し変化があります。
が、大枠としては指定した通りの出力結果になりますし、出力形式をもっと細かく指定することで毎回同じような結果を出力することも可能です。

さいごに

今回は議事録作成アプリを作成しましたが、フォーマットはこのままで、使用するプロンプトと項目名を変更することで全く異なるアプリケーションの作成も可能です。
例えば翻訳アプリや誤字脱字のチェック、メール文の作成など。
ほぼ同じフォーマットを使い回せるので、ぜひ1度AIエージェントとの連携を試してみてください。
また、Pleasanterに登録されているデータを使って分析、更新を行う際はPleasanterMCPサーバーもご利用ください。

2
3
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
Sign upLogin
2
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?