スポンサーリンク

【プリザンター×Claude Code】内田さんの「pleasanter-app-builder」を試してみた(後編)~Claudeアプリ・Codexでも試して、しくみをのぞいてみた

プリザンター
スポンサーリンク
※当サイトは広告を含みます

前編では、プリザンター開発者の内田さんが公開している「pleasanter-app-builder」を、VS CodeのClaude Codeで試したところまでをご紹介しました。

一言依頼するだけで、数分でダッシュボード付きのアプリができる。質問すれば答えてくれるし、修正もしてくれる。ここまででも十分驚きでした。

で、さらにちょっと気になったことがありまして。

  • VS Codeじゃなくて、Claudeのアプリでも使えるの?
  • ふだん使っているCodexでも使えるの?
  • そもそも、どういうしくみで動いているの?

後編では、このあたりを確かめてみました。最後に、私が「このツールはモックづくりにぴったり」と思う理由もお話しします。

前編をまだ読んでいない方は、こちらからどうぞ。

【プリザンター×Claude Code】内田さんの「pleasanter-app-builder」を試してみた(前編)~たった一言で!ダッシュボード付きアプリが出てきた( ゚Д゚)!

※この記事は、内田さんに了解をいただいたり、使い方を教わったりして書いたものではありません。公開されているREADMEをもとに、私が「どう使ったらいいかな?」「こういうものかな?」と勝手に試してみた記録です。使い方や説明に誤りがあれば、それは私の理解不足によるものです。

1.Claudeアプリでもやってみた

まずは、VS Codeではなく、IT初心者にはなじみやすい Claudeのデスクトップアプリ(パソコンに入れて使うClaude)でも動くのか。

※デスクトップアプリで使うときは、「Chat」ではなく「Code」に切り替えてから依頼します。ふだんの会話で使う「Chat」のままでは、このスキルは使えません。また、Codeに切り替えたら、作業するフォルダとしてスキルのあるフォルダ(pleasanter-app-builder)を選んでおきます。前編で紹介したVS Codeと同じで、フォルダを選ばないとスキルを読んでくれません。

題材は「備品貸出管理」にしました。ちょっとだけ設定を付けて、依頼しています。

依頼文はこちらです。

備品貸出管理を作って。AI機能、リマインダー、通知機能はつけないで。ちなみに当社は印刷・製本業を営む小規模な会社です。

※実際に印刷・製本業を営んでいるわけではなく、想像上の設定です。たとえば印刷業の方にモックを見せるとき、その業種らしいものが出てくればイメージがわきやすく、いっそう効果が期待できるはず。業種をちょっと伝えるだけで、そこまで気を使ってくれるのかを試してみたかったんです。

Claudeデスクトップアプリでの依頼と回答のイメージ

結果は、問題なくできました!

作ってくれたもの内容
備品台帳60件
貸出記録150件
ダッシュボード1つ
説明書Wiki
Claudeデスクトップアプリの成果物

VS Codeに慣れていない方は、いつものClaudeアプリから試してみるのもいいかもしれません。

2.Codexでもやってみた

次は、ふだん私がプリザンターのAI開発で使っているCodex(ChatGPT)です。

このスキルは、中身を見ると「手順書(文章のファイル)」と「Pythonのプログラム」の組み合わせです。それならCodexでもいけるんじゃない?と思って試してみました。

(1)私が実際にやった方法

今回は、Codex用にスキルを登録し直すことはせず、Claude Code用に置いたフォルダの手順書(SKILL.md)の場所を、そのまま教えるだけにしました。

依頼は、Claudeアプリと同じ内容です。

以下のClaude Code用スキルとプログラムを使って、備品貸出管理を作って。AI機能、リマインダー、通知機能はつけないで。ちなみに当社は印刷・製本業を営む小規模な会社です。

(SKILL.mdのフルパス)

Codexでの依頼と回答のイメージ

結果は、実行が通りました!

作ってくれたもの内容
備品台帳30件(検版用ルーペ、紙厚計、断裁用定規など)
貸出履歴80件
ダッシュボード1つ
説明書Wiki

備品に「検版用ルーペ」「紙厚計」が並んでいて、「印刷・製本業」と伝えたのがちゃんと反映されていました。

ただし、途中でちょっとだけつまずきがありました。

  • Codexが書き込める場所の外にフォルダがあったので、Codexが自分で作業用のコピーを作って実行した(元のファイルはそのまま)
  • 最初はプリザンターへの接続が止められて、接続を許可してからやり直した

どちらもCodexが自分で判断して対応してくれたので、私は許可を出しただけです。

(2)Codexで「スキル」として使う一般的な方法(※私は未検証)

Codexにも「スキル」の仕組みがあります。プロジェクト内の .agents/skills/ というフォルダに置くと認識され、$スキル名 で呼び出せるそうです。

$pleasanter-app を使って、備品貸出管理アプリを作ってください。

ただし、元のスキルにはClaude Codeを前提にした記述もあるので、コピーするだけでは動かないところが出るかもしれません。私はこの方法はまだ試していません。試すときは、Codexに「このClaude Code用のスキルを、Codexで使えるようにしたい」と相談してみるとよいと思います。

※参考:OpenAI公式:スキルの仕組み

3.ClaudeとCodexを比べてみた

(1)できあがったもの

同じ依頼でも、できあがったものはちょっとずつ違いました。

ClaudeアプリCodex
テーブル備品台帳+貸出記録備品台帳+貸出履歴
テストデータ60件+150件30件+80件
ダッシュボードありあり。一番下にカンバン
説明書(Wiki)ありあり

見比べてみると、このお題に関しては、私はCodexの方が好きかな。

  • ダッシュボードの一番下のカンバンで、「今貸し出し中のものは?」「今貸し出せるものは?」がひと目でわかる
  • 貸出履歴の一覧に、日付が表示されている

とはいえ、お題にもよるでしょうし、好みの問題もありましょう。ほぼ同じと思ってよいと感じました。同じスキルとプログラムを使っているので、大きな差は出にくいのかもしれません。

(2)話し方の印象

こちらはおまけです。

Claudeさんと話したあとにCodexさんと話すと、「なんか固いな」と感じました。Claudeさんは物腰柔らかな印象でした。

でも、逆に「Claudeさん、真面目すぎて融通きかないな」と思うこともあれば、Codexさんが真面目な顔してけっこうはっちゃけたこともやってくれたり。

それぞれ人格があるみたいで(?)、なんだかおもしろいですね。

4.どこまでがAI?スキル?プログラム?

前編でも書きましたが、いちばんプリザンターを知っている内田さんが作ったものです。どうなっているのか知りたくて、Claudeさんにいろいろ質問してみました。

(1)AIが書くのは「設計図」だけ

いちばん驚いたのは、AIが書くのはアプリの「設計図」だけということです。

プリザンターへの登録や、正しくできたかのチェックは、用意されたPythonのプログラムがやります。

流れは、こんな感じです。

  1. 私が依頼する(「売上・経費管理を作って」)
  2. Claudeが、手順書と仕様メモを読んで、アプリの設計図(spec.json)を書く
  3. Pythonのプログラムが、設計図をチェックして、プリザンターに登録する
  4. プログラムが、テストデータ・ダッシュボード・説明書を作り、正しくできたか確かめる

普段私はCodexにプリザンターのJSONをまるごと書いてもらっています。それに比べて、このツールがあんなに速かったのは、たぶんこのしくみのおかげです。AIに任せる部分を絞って、決まった作業はプログラムに任せる。だから速くて、正確なんですね。

ちなみに、中身の分量はこのくらいでした。

中身分量(おおよそ)役割
Pythonのプログラム約1,800行登録・チェック・検証などの実作業
手順書・仕様メモ(文章)約1,400行AI向けの作業手順と「カンペ」

(2)役割分担をまとめると

だれがやること
Claude(AI)業務を考えて設計する。依頼をスキルの機能に当てはめる。テストデータの中身を考える。修正のときに判断する。部品で足りないところは自分でコードを書く
スキル(手順書・仕様メモ)作業の手順、既定値、設計のコツ、プリザンターの仕様を教える
プログラム(Python)設計図を設定に変換してチェック。プリザンターへの登録、検証、ダッシュボードや説明書の作成、設定だけの更新

私なりにまとめると、こうです。

Claudeが「考えて」「命令する」。考えるときはスキルの手順書や仕様メモに従う。命令するときは手順に従って、用意されたプログラムを使う。用意されていないところは、自分でコードを書いて補う。

Claudeさんにこのまとめを見せたところ、「大筋そのとおり」とのこと。そのうえで、次の3点を補足してくれました。

  • 優先順位は「依頼」>「スキルの既定値」。依頼に合わない既定値は変える
  • Claudeが自分で書いたコードには、プログラムの自動チェックが付かない
  • フォルダの決まりごと(APIキーを表示しない、削除の前に確認するなど)は、いつも守る

前編の実験④で、無理を言って作ってもらった「規格外」のグラフ(スキルの部品では描けない形)は、まさに「用意されていないところを自分で補う」部分だったんですね。

(3)できないこともある

便利なツールですが、何でもできるわけではありません。2026年11月13日時点の資料によると、次のようなものは対応していません。

  • 期限付きテーブル
  • アクセス権の設定
  • プロセスや状況による制御
  • ルックアップ

また、設計図の型に沿って作るので、できあがるのはどうしても「ひな型に準じたもの」になります。

5.試してわかった使い方のコツ

前編・後編を通して試してみて、「こうするといいかも」と思ったことをまとめます。

NOコツひとこと
1まずはアプリ名だけで1回作る動くものが数分で出てくるので、全体像をつかめる
2慣れたら、依頼文に4つ書く「困りごと」「要らないもの」「ダッシュボードで見たいもの」「規模感」
3修正は「直して」でよい作り直しにならず、データも残る
4確認してほしいことも依頼する「変更前後の違いと、データが残っているかも報告して」
5勝手に進めてほしくないときは、そう伝える「まだ実行しないで、できるかだけ答えて」
6ツール本体を守る「手順書やプログラムは変えないで」と伝えると安心。ただし、作業中にわかった仕様を仕様メモに書き足すのはスキルの決まった手順なので、その追記は想定どおりの動きです
7わからないことはそのまま聞く「これって連携してる?」「どこまでがスキル?」など、理由つきで答えてくれる

特に5の「まだ実行しないで」は、AIと一緒に作業するとき全般に使える一言です。おすすめです。

6.まとめ:モック・たたき台づくりにぴったり

(1)すごい!はやい!だけど、だけど、実務でそのまま使う想定ではない

やっぱり、すごい!はやい!

一言言うだけで、数分で機能付きのプリザンターサイトができあがります。ゼロから手作業で組んでいくより、格段に速いです。

ただし、ひな型に準じて作られるので、実務でそのまま使うことを想定したツールではありません。内田さんも「本番環境では使わないで」と書いています。

私は、モック(試作品)やたたき台づくりに使うのが、いちばん力を発揮するのではないかと思いました。

いいところなぜモック向き?
一言で数分打ち合わせの前に、さっと用意できる
ダッシュボードとグラフが自動で付く「見栄え」は一定以上の品質が期待できる
テストデータ付きより、本番のイメージが付きやすい
できたものから気づきがある「ここをこう変えれば」「なるほど、こうテーブルを分ければいいのか」とヒントがもらえる

ちなみに、できたアプリでは集計(サマリ)がたくさん使われていました。私は「サマリって、こうやって使うのか」と、プリザンターの機能の使い方の勉強にもなりました。

(2)私がモックを大事にする理由

私は、最初のモックに結構力を入れます。

プリザンターを見たことがない人。使っているけど、いまいち使い方がわからない人。そんな方にとって、「初対面」の印象はかなりインパクトがあると思っています。

人と同じで、初対面の好印象は大事。最初に心をつかむと、そのあとも好印象を持ってもらえると思っています。

そして、「初対面の印象」と同じくらい大事なのが、「提供の速さ」です。

モックづくりにもたもたしていたら、話が立ち消えになってしまうかもしれません。

なんなら、「こんなのできない?」という打ち合わせの場で、その場で作ってみせる。それだけでも、かなりインパクトがあると思いませんか?

(3)使うハードルは意外と低い

PCが得意ではない私でも、使うハードルは低いと感じました。

いちばんの近道は、この2つです。

  1. AIにGitHubのURLを渡して、「これ使いたいんだけど、どうしたらいい?」と聞く
  2. 1回、一言で依頼してみる

ただし、Claudeで使うにはProプラン以上が必要です。会社で使う場合は、会社のルールも確認してください。

(4)これからやってみたいこと

私はふだん、Codexに「プリザンター開発方針」をまとめたファイルを置いて、AI開発をしています。

今回、内田さんのツールの「AIには設計図だけ書かせて、あとはプログラムに任せる」という考え方に触れて、とても刺激を受けました。

このツールをそのまま使うのではなく、自分の開発方針といいとこどりできないか。今度はそんなことを試してみたいと思っています。

(5)今回のポイント

今回のポイントは、次の3つです。

  • Claude Codeだけでなく、ClaudeアプリやCodexからも使えた
  • AIが書くのは主に設計図。登録やチェックはプログラムが行うから速くて正確
  • 本番用ではなく、モック・たたき台づくりでこそ力を発揮する

完成形を細かく説明できなくても大丈夫。まずは一言、依頼してみてください。出てきたものを見るだけで、「こういうふうに作ればいいのか」と、きっと新しい発見があるはずです。

前編・後編と長くなりましたが、最後までお読みいただき、ありがとうございました。これからも、プリザンターやAIを「試してみてわかったこと」を、非エンジニア目線でお届けしていきます。

免責事項

  • 本記事は、筆者個人の環境(2026年11月時点)で試した結果を紹介するものです。そのまま動作することを保証するものではありません。
  • 本記事は内田さんの了解や監修を受けたものではなく、筆者が独自に試した内容です。
  • pleasanter-app-builderは内田さん個人による非公式の参考実装です。本番環境や業務データでは使わないでください。
  • Codexでの利用は、作者が想定している使い方ではありません。筆者が試した一例としてご覧ください。
  • 記事中のデータは、すべて架空のテストデータです。
  • 料金や仕様は変わることがあります。最新の情報は公式ページでご確認ください。

参考

コメント

タイトルとURLをコピーしました