Single Fileから始める FREE
AIプロンプトとテンプレートを活用してウェブページを作成・デプロイする流れを案内します。QuickStartで最も早く始められる方法です。
QuickStartにログインし、左メニューからシングルファイルをクリックするとAIコーダーエディタが開きます。HTML・SCSS・Vue.jsを1画面で編集できる統合開発環境です。
エディタ上部のテンプレートドロップダウンをクリックすると、ランディングページ・ポートフォリオ・ダッシュボードなど用意されたテンプレートが一覧表示されます。コミュニティ共有テンプレートも利用できます。
テンプレートを読み込むとHTML・SCSS・JavaScriptがエディタに表示されます。任意の箇所を編集して上部の実行ボタンを押すと即時にプレビュー反映されます。AIにプロンプトでコード生成を依頼することも可能です。
初回デプロイにはRailwayアカウントが必要です。設定 > アカウントでRailway APIトークンを登録すると連携完了。一度設定すれば以降すべてのデプロイに自動適用されます。
エディタ上部のデプロイボタンをクリックするとデプロイが始まります。ファイル生成・サーバーアップロード・ビルドの各ステップが表示されながらすべて自動で進み、通常1〜2分で完了します。
デプロイが完了するとQuickStartが提供する無料ドメインが自動で紐づけられます。ドメインリンクをクリックすると、作成したウェブページがインターネット上で公開されていることを確認できます。おめでとうございます!
プロジェクトから始める
フロントエンドとバックエンドを備えたフルスタックWebアプリケーションを構築できます。プロジェクトは独立した出発点ではありません — データベースまたはマクロでまず用意したコンテナ(ドメイン)の上にデプロイされる仕組みなので、データベース/マクロで始めるを先に進めてから戻ってきてください。
プロジェクトメニューから「新規プロジェクト」をクリックします。名前と説明を入力し、既に作成済みのドメイン(コンテナ)とデータセットを選ぶと、そのコンテナ上にプロジェクト構造が生成されます。ドメインはプロジェクトランタイムが動くDockerコンテナを指すため、必ずデータベースまたはマクロ経路で事前にプロビジョニングしておく必要があります。
プロジェクト内にプログラムを追加します。各プログラムは1つのページや機能単位を表します。HTML/CSSでUIを作り、PHPでサーバーロジックを書きます。AIプロンプトで自動生成することも可能です。
プログラムをURLにマッピングするルーターを設定します。例: 「掲示板」プログラムを/boardに接続すれば、訪問者がそのURLでアクセスできます。GET/POSTメソッドも指定可能です。
デプロイボタンを押すと8ステップの自動デプロイが開始します: Pack生成 → DB準備 → データ暗号化 → サーバーアップロード → ビルド → 設定 → テスト → 完了。各ステップの進捗をリアルタイムで確認できます。
デプロイ完了後、プロジェクトに紐づくドメインにアクセスして結果を確認します。すべてのプログラム・ルーター・DB接続が正常に動作するかテストしてください。
データベースから始める PRO
最も軽量な出発点です。この経路を選ぶと、DBエンジン1種(MySQL・MariaDB・PostgreSQL・MongoDBから選択)+ PHP/Laravelバックエンド + npm環境がバンドルされたDockerコンテナ(ドメイン)が自動プロビジョニングされます。不要な機能を削ぎ落とした最小構成のため、DB + シンプルなWebバックエンドのみで十分な方、リソースを最小に保ちたい方に最適です。データ保存・管理、REST API自動生成から始めましょう。より豊富な環境が必要になればマクロ経路へ切り替えてください。
データベースメニューで「新規データセット」をクリックするとウィザードが開きます。ステップ1でDeploy(RailwayでDBコンテナを新規プロビジョニング)またはConnect(既に運用中の外部DBのホスト・ポート・認証情報を入力して接続)を選び、MySQL・MariaDB・PostgreSQL・MongoDBの中からエンジンを選択します。
DBエディタでテーブル一覧を確認し、各テーブルのフィールド構造を閲覧します。新しいテーブルの作成や既存テーブルの修正も可能です。
クエリエディタにSQLを入力して実行すると結果が即座に表示されます。SELECT・INSERT・UPDATE・DELETEなどすべてのSQL文を利用でき、AIに自然言語でクエリを依頼することもできます。
テーブルを選んでAPI生成ボタンを押すと、API構造をマッピングするインターフェースが開きます。デフォルトのままCRUD(作成/取得/更新/削除)エンドポイントを一括生成することも、公開フィールド・パラメータ・レスポンス形状をフロントの要件に合わせて再構成してから生成することもできます。
生成されたAPIをレイアウトビルダーのブロックにバインドしたり、プロジェクトのプログラムから呼び出したりして、実データに基づくWebサービスを構築します。CSV/JSONでデータをインポート/エクスポートも可能です。
マクロから始める MAX
データベース経路よりはるかにリッチなランタイム環境が必要なときに選ぶ出発点です。この経路を選ぶと、MariaDB・PostgreSQLが自動バンドルで一緒に立ち上がり、MongoDBはオプションで追加可能、さらにPython・Node.js・curl・jqなどのCLIツール、定期タイマー自動化、ffmpegなど、今は要らなくても将来必要になるかもしれない大半のツールがプリインストールされたDockerコンテナ(ドメイン)が自動プロビジョニングされます。データ収集・加工、外部API連携、メディア変換、スケジュール自動化などの複合ワークロードに最適です。「DB+PHPで十分か、将来拡張が必要か」と迷うならこちらが安全な選択です。
マクロメニューで「新規マクロ」をクリックし名前を入力します。入力パラメータが必要なら名前・型・デフォルト値を定義してください。パラメータは実行時に値を受け取る変数です。
コードエディタでNode.jsまたはPHPの自動化ロジックを書きます。外部API呼び出し、データ加工、ファイル処理など自由に記述可能です。run_dataオブジェクトからパラメータと実行コンテキストにアクセスできます。
書いたコードをすぐにテストできます。クイックテストを押すとマクロが即実行され、結果が下部パネルに表示されます。テーブル・JSON・ダウンロードリンク・メッセージなど複数の結果形式に対応しています。
マクロを定期的に自動実行するには、開始時刻 (HH:MM) と 間隔 (分) の2つを入力するだけです。例:00:00 + 5 → 毎日0時を起点に5分ごと、03:30 + 1440 → 毎日午前3時30分に1回。
マクロをRailwayサーバーにデプロイすれば、独立した環境で安定稼働します。デプロイ後はAPIエンドポイントが作成され、外部からHTTPリクエストでマクロをトリガーできます。
QuickStart 概要
まず以下のコアコンセプトを理解しておくと、QuickStartの各機能がどのように連携するかがぐっと見えやすくなり、サービスから得られる価値も大きく広がります。上部のカテゴリ別コンセプトマップを眺めてから、任意のチップをクリックして詳細カードに飛んでください。各説明内のクロスリンクで関連コンセプト間を自在に行き来できます。
コンセプトマップ
コアコンセプト
ドメイン
デプロイ
deploy_logsに記録されます。再デプロイは通常1分程度で完了します。 エージェント
プロジェクト
プログラム
プログラムビルダー
フック
スキャフォールド
ルータ
:id)を宣言的に記述。ルートの追加・削除はデプロイ不要で即時反映されます。 リビジョン
ソリューション
データセット
パーサー
ブロック
Preset
フレーム
Scene
マクロ
翻訳
Patch
User
チーム
team_idsカンマ区切りで保存されます。 アーキテクチャ
QuickStartの技術構造を理解すると、より効率的にサービスを活用できます。
レイヤー構造
クライアント(ブラウザ)
- Single File · プロジェクト · データベース · マクロ · データ収集の専用エディタ
- AIとチャットしながら結果を即時プレビュー
- プロジェクト機能内で40言語切替とプレビュー
- ログイン情報・編集中の内容・テーマ設定をブラウザに安全に保存
- レイアウトビルダーのドラッグ&ドロップキャンバスでブロック配置
- 大きなファイルは中央サーバーを経由せず、ユーザーコンテナに直接アップロード・ダウンロード
QuickStartサーバー
- アカウント · 料金プラン · 決済管理
- プロジェクト · ソリューション · ドメインの一覧と状態を追跡
- デプロイ開始時、各ステップを正しい順序で自動実行
- ブラウザがコンテナと直接やり取りするための一時的な転送許可証を発行
- UI描画に必要なページやリソースを配信
- 一般ユーザーのデータは中央サーバーを通らないので、負荷とコストが低く抑えられる
Dockerエージェント(ユーザーサーバー)
- ユーザーのドメイン(コンテナ)内に常駐
- プログラム · ブロック · ルータ · データセットの実データを直接作成・読み込み・更新・削除
- リモートファイル操作 — アップロード · 編集 · ダウンロード
- デプロイ済みのプログラム · マクロ · データ収集タスクを直接実行
- 専用のセキュリティキーと一時許可証でリクエストを検証
- ユーザーデータはこのコンテナ内に隔離され、他ユーザーと混在しない
Railwayホスティング
- 新規コンテナのプロビジョニングとデプロイ環境を提供
- 既定ドメインの自動割当と独自ドメイン接続対応
- トラフィックに応じて処理能力とメモリを自動スケール
- 実行ログとステータスメトリクスを集約
- QuickStartが公式連携チャネル経由でコンテナ操作を指示
レイヤー間のネットワーク経路
| チャネル | エンドポイント | プロトコル | 流れる内容 |
|---|---|---|---|
| 制御チャネル | クライアント ↔ QuickStartサーバー | セッションベースのセキュア接続 | ログイン、プロジェクト一覧、設定変更などの日常的なリクエストを運びます。ペイロードが小さいためUIは機敏で、サーバー負荷も低く保たれます。 |
| データチャネル(サーバーバイパス) | クライアント ↔ Dockerエージェント | 使い捨ての転送認可 | ファイルのアップロード・ダウンロード・リモート編集・大きなクエリ結果がここを流れます。ユーザーのブラウザがユーザー自身のコンテナと直接通信し、中央QuickStartサーバーは経路に入りません。大容量転送でもサーバーのストレージと帯域コストはゼロで、速度も維持されます。 |
| 協調チャネル | QuickStartサーバー ↔ Dockerエージェント | コンテナスコープのセキュリティキー | ユーザーコンテナの健全性確認、利用可能機能の探索、デプロイ周辺の管理シグナルのやり取りに使用。ここに実ユーザーデータは一切流れません。 |
| プロビジョニングチャネル | QuickStartサーバー ↔ Railway | インフラ提供事業者との公式連携 | 新規コンテナ作成、デプロイリクエスト、ドメイン接続などのインフラ指示を伝達します。ユーザーが自身のRailwayアカウントをQuickStartに登録している場合、これらはそのアカウント内で実行されます。 |
| 包含 | Dockerエージェント ⊂ Railway | — | エージェントはRailwayが管理するコンテナ内部で動作します。Railwayがコンテナのライフサイクル・リソース・ネットワークを所有するので、インフラレベルの問題はそこで吸収され、ユーザーは自分のサービスロジックに集中できます。 |
中央サーバーは制御と調整のみを担当し、実データはユーザーのブラウザとユーザー自身のコンテナ間で直接やり取りされます。中央にボトルネックがないので、負荷が高くても転送が速く、サーバーのストレージと帯域コストも大幅に低く抑えられます。何より、各ユーザーのデータは自分のコンテナ内に隔離される — 他ユーザーや中央サーバーと混ざる経路そのものが存在しないので、データセキュリティがアーキテクチャ自体の特性として保証されます。
料金プラン
QuickStartは無料プランから始められます。必要に応じてPROまたはMAXプランにアップグレードしてください。
| プラン | 利用可能サービス | おすすめ |
|---|---|---|
| FREE |
シングルファイル
レイアウトビルダー
スライドショー基本機能
ドメイン管理
コミュニティサポート
|
単一ファイルのページとしてアイデアを手早く公開したい個人 |
| PRO |
+ FREEのすべて
フルスタックプロジェクト
データベース
Webクローリング
スライドショーのパラメータカーソル
|
DBとWebクローリングも必要なフルスタックWebアプリ運営者 |
| MAX |
+ PROのすべて
コーダービルダー
マクロ自動化
スケジュールクローリング
ディスプレイチャネル
|
スケジュール自動化と高度なビルダー機能を必要とするパワーユーザー |
シングルファイル
1つのファイルでWebページを作る最もシンプルな方法。
- {{ item }}
/service/single を開きます。上部ツールバーは3ゾーンに分かれています。
- 左 — 履歴 · ガイド · アプリタイトル · 保存 (💾)
- 中央 — テンプレートドロップダウン (11選択肢)
- 右 — 共有リスト · 共有 · コピー · 実行 ▶ · デプロイ 📦
本体には4つのエディタタブ (prompt · html · scss · vuejs) と右側のライブプレビューがあります。
開始方法は2つ:
- 既製テンプレート — ドロップダウンに11選択肢: E-Commerce · リアルタイム株価チャート · お気に入りダッシュボード · SaaS料金 · キオスクメニュー · レストラン予約 · YouTubeクリエイターハブ · 商品詳細 · チャットアプリ · イベントカウントダウン · 管理ダッシュボード。選んだ瞬間に4タブすべてが埋まります。
- AIプロンプトで一から — promptタブに欲しいもの(例:「3カテゴリタブのあるカフェメニューページ」)を記述し、AIボタンでHTML/SCSS/Vueタブを自動生成。
タブを切り替えて各レイヤーを編集します。
- prompt — AI再生成に使う説明。編集+再生成でコードが更新されます。
- html — 構造とテキスト。行番号 + Ctrl+F 検索。
- scss — 色、フォント、余白。ほとんどのテンプレートはファイル上部でテーマ変数を定義しています。
- vuejs — データとインタラクティビティ。
data() { return { ... } }、methods: { ... }、mounted()を使用。
const/let、アロー関数、テンプレートリテラルは禁止。var と function を使ってください。
ツールバー右側の 実行 ▶ をクリックするとプレビューパネルにページがライブレンダリングされます。編集後に再度クリックして更新。
左上の 履歴 ボタンで最近の保存版を開きます。行の → ロード アイコンでその状態に復元 — 編集で壊れた時のセーフティネットです。
成果物を世に出す方法は2つ:
- デプロイ 📦 — ツールバー右端のボタン。Railwayアカウント接続後、デプロイ進捗モーダルが走り、1〜3分で無料ドメインにページが公開されます。
- 共有 — ツールバーの共有アイコン。タイトル/説明/タグを追加してコミュニティに公開 — 他ユーザーがフォークできます(テンプレート共有であり、ライブデプロイではありません)。
プロジェクト
フロントエンド+バックエンドを備えたフルスタックWebアプリを開発。
- {{ item }}
メニューから サービス > プロジェクト を開きます。レイアウト:
- 左サイドバー — 青い [+ 新規プロジェクト] / [+ 新規チーム] ボタンと、最近、公開ソリューション、マイプロジェクト、チームのセクション。
- 上部パンくず — 一覧 ↔ 詳細 ↔ プログラム ↔ デプロイ のビューを切替。
- 本体 — 各プロジェクトのドメインバッジ、DBタイプ、プログラム/ルータ数を示すカード。
[+ 新規プロジェクト] をクリック → ウィザードモーダル。
- ステップ 1 — 機能カードとフロー図。
- ステップ 2 — 設定
- ドメイン (必須) — あなたの既存ドメインから1つ
- データセット (必須) — このプロジェクトが使うDB
- プロジェクト名 / 説明
- チーム割当(チェックボックス)
- 下部の [保存] — ドメインとデータセット両方を選んだ後にのみ有効化。
プログラム はプロジェクト内の1ページまたは1つの機能単位です。作成フォームで基本情報を埋めた後、そのままコードエディタに飛び、Blade + SCSS + Vue を1画面で書きます。
1) 新規プログラム作成
プロジェクト詳細のツールバーに [+ 新規プログラム] と [+ 新規ルータ] が表示されます。新規プログラムをクリックするとフォームモーダルが開きます。
- プログラム名(例:
home,admin_dashboard) - 説明 — この画面/機能は何か、一行メモ
- タイプ — frontend(HTML/CSS/JS)/ backend(PHP)
- ルータ — 既存ルータを選ぶ、またはエイリアス + URLパス + HTTPメソッドでインラインで新規作成
2) コードエディタ起動と画面レイアウト
プログラム行の アイコンをクリックするとエディタビューに切り替わります。画面は3ゾーン構成。
- 上部パンくず + ツールバー — 現在のプログラム名、保存状態インジケータ、ツールボタン群が同一行に。
- 左サイドバー — 同プロジェクト内の他プログラムリスト。各項目に (コード)と (ビルダー)のクイックアイコンがあり、ビュー切替できます。
- 中央3カラムエディタ — 3つの CodeMirror 6 パネル(HTML / CSS / JavaScript)が横並び。パネルをクリックすると focused でハイライトされ、エディタテーマはダーク/ライト設定に自動追従します。
3) 各タブの中身
- HTML — プレーンHTML + Blade ディレクティブ (
@if,@foreach) と@{{ ... }}出力。サーバーサイド変数、条件、ループをテンプレートに直接書きます。 - CSS — SCSS 構文(ネスト、
&参照、変数、mixin)そのまま。デプロイ時に自動コンパイル。 - JavaScript — Vue 3 Options API 形式(data / computed / methods / mounted)。ランタイムが自動で取り、HTMLカラムのテンプレートにバインドします。
標準のCodeMirrorショートカットは期待通り動きます: Ctrl+F エディタ内検索、Ctrl+Z アンドゥ、Ctrl+/ コメント、括弧/タグの自動クローズ、ソフトラインラップ。
4) 編集状態と保存サイクル
1文字でも変えた瞬間、上部バーに 未保存 が表示され未保存変更を知らせます。[ 保存] をクリックすると3タブが同時に送られ、成功で 保存済 のチェックが一瞬出ます。
各保存は3カラムをプログラム本体に書き込むと同時に、その瞬間を リビジョン として記録します。保存 = 自動バージョンスナップショット — 後からいつでも戻せます。
5) Deploy on Save — 保存のたびに即ライブ反映
保存の隣の [Deploy on Save] トグルをONにすると、保存のたびに変更がプロジェクトの対象先(例: メインサーバー)へ 自動デプロイ されます。プッシュ後に短い「N件デプロイ完了」バッジが一瞬表示されるので、別途Deployボタンを押す必要なく「編集 → ライブ」のループが自己完結します。トグルはプロジェクトごとに記憶され、一度ONにすれば維持されます。
6) 上部ツールクラスタ一覧
- Database — データセットバインディング ポップアップを開く。変数名を付け、テーブルを選び、WHERE/LIMIT/ORDERを設定すると、クエリ結果がその変数名でプログラムに自動注入されます。
- Builder — 同じプログラムのブロックベース編集ビューに切替。CodeビューとBuilderビューは出力を共有します。
- Code Search — プロジェクト全体の検索&置換パネル(7参照)。
- Revisions — Diffパネル付きのリビジョン履歴(8参照)。
- Extension Guide — VSCode拡張でローカルから同プロジェクトを編集・デプロイする方法のポップアップ。
7) プロジェクト全体の検索&置換
上部にキーワードを入力し Enter または ボタン。スコープタブで2択 — Project(現プロジェクトの全プログラム)または Revisions(過去スナップショット含む)。
- 結果に タイプバッジ(HTML / CSS / JS)、プログラムID、プログラム名、マッチ数が表示。
- タイプフィルタタブ All / HTML / CSS / JS で単一カラムに絞込、各タブにマッチ数を表示。
- プログラム名横の矢印をクリックするとそのプログラムのエディタに直接ジャンプ。
- 行の [Show More] で右側に コンテキストパネル が開き、各マッチの周辺コードが見えます。
Replace は2行目。スコープ(All / HTML / CSS / JS)を選び、検索語と置換語を入れ を押すと、「N件のファイルで変更されます」の確認が出て、Yesでプロジェクト全体置換が一気に実行されます。
8) Revisions · 履歴とロールバック
各保存がここにスナップショットとして追加されます。パネルを開いた瞬間、右側で 最新リビジョン ↔ 現在の編集 の自動Diffが実行されます。
- 左: リビジョン一覧(ページネーション付き)。各行に3つのアクションアイコン:
- Revert — このリビジョンでエディタを上書き(未保存変更は失われます)。
- 現在とDiff — このリビジョン ↔ 現在エディタにあるもの。
- 前回とDiff — このリビジョン ↔ 1つ前のリビジョン。
- 右: HTML / CSS / JS タブ付きの 横並びDiff。実際に変更のあったタブが自動選択されます。
9) 作者が実際に踏む順序
- プログラム行の アイコンからエディタを開く。
- 必要に応じて HTML(Blade) → CSS(SCSS) → JS(Vue) タブで書く。
- データが必要なら Database、プログラム横断検索なら Code Search、履歴と比較なら Revisions。
- [保存] を押して「保存済」を待つ。Deploy on Save がONならデプロイも同時実行。
- 何か壊れたら、Revisionsパネルから適切なスナップショットに戻す。
- 複数プログラムにまたがるリネームは Code Search → Replace で1回の確認操作で実行。
詳細ビューの折りたたみ可能なルータセクション、または [+ 新規ルータ] でルータを登録します。
- エイリアス — 内部識別子(例:
home,api_orders) - URLパス — 公開パス(例:
/home,/api/orders) - HTTPメソッド — GET / POST / PUT / DELETE / ANY
プログラムフォームのルータセレクタでルータをプログラムに接続 — 訪問者がそのURLに来るとプログラムがトリガされます。
function list_orders() のような関数名からルータエントリが自動提案されます。
プロジェクト一覧カードの 🚀(ロケット)アイコン でデプロイモーダルを開きます。
- デプロイモード を選択: integrate(既存Docker再利用)· rebuild · new
- [デプロイ開始] をクリック → 9ステップパイプラインが走る(完了ごとに緑):
① パック作成 → ② DB準備 → ③ データ準備 → ④ サーバー転送 → ⑤ Dockerビルド → ⑥ Dockerデプロイ → ⑦ ドメイン接続 → ⑧ インストール完了 → ⑨ サービス安定化 - 完了するとドメインURLがライブになり、すぐアクセス可能に。
コードビルダー (Code Builder)
1つ(または複数)のDBテーブルに対するリスト · 詳細 · 検索 · CRUD画面と必要なPHP/Vueコードを、タブベースのウィザードで設計し、[Builder]ボタン一発でBlade + Vueの完成プログラムに変換するツールです。プログラム一覧の アイコンから入ります。テンプレートを手で書かなくても、DBスキーマ → 画面 → インタラクションまでの流れが体系的に自動化されます。
- {{ item }}
プログラム行の アイコンから Code Builder を開きます。上部に8つのステップタブ(DB · List · Detail · Search · Hook · Style · Code · Menu)があり、ほとんどのプログラムは左から右に一度だけ進めれば完成します。
流れを一目で
- [1] DBテーブル選択
フィールド選択
WHERE · ORDER - [2] Listフィールド配置
グループ · ソート
5種のレイアウト - [3] Detail · Searchフォーム形成
コンポーネント選択
insert / update 分離 - [4] Hook · Codeフックを注入
[Builder] でコード生成
スニペット再利用 - [5] Menu4階層ツリー
[menu:code]
共通include
DBタブ詳細 — 接続が切れていると「DB未接続」バナーと再接続ガイドが最初に表示されます。接続が生きていれば、パネルは次のように開きます:
- #list(編集可) — メインテーブル1つ。ドロップダウンから選び [Select] を押します。このテーブルの行を編集 / 削除 / 挿入することになります。
- #list2(閲覧のみ) — 結合用の副テーブル(例: ラベルや名前の引き込み)。
- #list3, #list4 … — サイドバーの で追加テーブルを足します。
- 3つのフィールドピッカー — 同じカラム一覧から「List用」「Detail用」「Search用」を別々に複数選択。各ピッカー横のチェックボックスで一括 on/off。
- DB Search Option —
WHERE・ORDER BY・LIMITの3行、オプションのRaw Query。これらがリストのデフォルトクエリフィルタになります。 - 下部の [Update] でステップ保存、[Reset] でやり直し。
DBタブで選んだ「List用フィールド」が左に候補として並びます。このタブでは リスト画面の見た目と各カラムの挙動 を定義します。
5つのレイアウトから1つ を最初に選ぶと、下のオプションがそれに合わせて自動調整されます。
- datatable — ソート / ページネーション内蔵のテーブル。
- table — カラムごとのソートトグル付きプレーンテーブル。
- grid — カードグリッド。
- modal — 行をその場でモーダル展開するリスト。
- slots — レイアウトフレームのスロットに埋め込み。
アイテム(フィールドカラム)を追加 — 左側の [+ Add Item] で候補ドロップダウンを開く。既存フィールドを選ぶか、+ new で仮想フィールド(計算・結合用)を追加。
- 各行: header_value(表示ラベル)· header_text(説明)· width · mutator(フィールド別カスタムコード)· sortable · linkable · use_opt(オプション値)· (表示/非表示切替)。
- ↑↓ で並替、 で削除、 魔法の杖でAIアシストコード。
グルーピング — 右上の [Create Group] で選択フィールドを1〜5グループにまとめます。〜 をタップして、アイテムを各グループに割当。
- グループモードで [Toggle Panel] を押すと グループ編集パネル に切替わります。ここでグループごとに グループ名(内部識別子)、グループヘッダ(画面に出るタイトル)、レイアウト(グループ内カラムの並び)を入力。パネル上部の グループ表示方式 で複数グループの見せ方を決めます — タブ、横並びボックス、1行入力グループ。
下部の [Update] でステップ保存。
Detailタブ はリストの行をクリックした時に開く 詳細 / 編集ポップアップ(モーダル) を定義します。レイアウトは Listタブとほぼ同じで、肝は フィールドごとの入力コンポーネント 選択です。
- Component ドロップダウン — フィールドごとに入力タイプを選択: text · textarea · select · checkbox · radio · date · datetime · file · editor · hidden …
- opt_name / opt_value — コンポーネント固有の追加オプション(selectの選択肢、fileの拡張子、dateの書式など)。
- insert / update 三角アイコン — フィールドを追加フォーム、編集フォーム、両方のどれに出すか切替。例:
id/created_atは通常編集時のみ。 - required (+/-) トグル — 必須入力フラグ。
- layout — セル配置 / 幅(1/2、1/3、フル幅 …)。
- 上部ツールバーで 主キーカラム(行を一意に特定するカラム)と 詳細ページキー(詳細ページを開くときURLに乗るカラム)を指定。
Searchタブ は同じエディタを共有。違いは:
- Match mode — 入力値をどうDBと突き合わせるか: contains(部分一致)· equals(完全一致)· one-of(コンマリストと照合)· full-text(長文の単語検索)など。
- コンポーネントは検索UXに合わせた選択 — 自由入力、ドロップダウンフィルタなど。
検索入力はリスト上に自動配置され、送信するとDBタブで設定した WHERE と AND で結合されます。
ここまででステップ 1〜3 が画面の「素材」を埋めました。いよいよ 細かな挙動、権限、カスタムロジック を加えてコードを出します。
Hookタブ — 生成されるHTMLとJavaScriptのスキャフォルドが小さな図で見え、カスタムコードを注入できる フックポイント(バッジ)が並びます。
- 上部のミニ HTML / JavaScript 骨格 — <?php ... ?>、<style>、<body>、モーダル、data / computed / mounted / methods の位置がマークされ、フックがどこに入るか正確に見えます。
- 各フック行を で展開してエディタを開きます。ダブルクリックで ワイドモード。
- エディタ内で右クリック → Save Snippet / Load Snippet。頻出ロジック(ログインチェック、権限ガード、アップロード前処理など)をidentで保存し、別プログラムで再利用可能。
Styleタブ — このプログラム用の CSS / SCSS エディタ。css_integrate をONにするとプロジェクトのグローバルCSSバンドルと統合。Backend Code をONにすればPHPスニペットも添付できます。
Codeタブ · 実際の生成 — ここが [Builder] を押す場所。
- 2つのCodeMirrorエディタ — 左に Blade テンプレート、右に Vue Script。ステップ 1〜3 とフック入力から組み立てられたコードがプレビューされます。
- Session Condition、4セル — Add / Delete / Read / Detail。各CRUD操作をセッション述語(例:
user_level>=3)でガード。 - 機能トグルグリッド — 再利用可能な機能(CSV / Excel エクスポート、複数削除、ソート永続化 …)をONにし、必要なパラメータを設定。
- 下部の [Builder] ボタンですべてを Blade + Vue Script に組み上げ、プログラムの実コード に直接書き込みます。以降は通常のコードエディタが担当 — 編集・保存・デプロイは通常通り。
[menu:code] shortcodeプログラムが複数になると 共有ナビゲーション が欲しくなります。Menuタブは 最大4階層のメニューツリー を組み立てるウィザードで、1行のショートコードで任意の場所に差し込めます。
メニューグループ — プロジェクト内に1つのメニュー定義を収める名前空間。
- ドロップダウンから既存グループを選ぶか、新しいグループコード(英数字 + アンダースコア、2〜9文字)を入力して [Create Menu Group]。
4階層ツリーエディタ — グループを選ぶと左に Depth 0 テーブルが現れます。行を掘ると右に次のdepthが開き、深く進むにつれ最大4カラムが並びます(Depth 0 → Depth 3)。
Depth 0 ┐
├─ Depth 1 ┐
│ ├─ Depth 2 ┐
│ │ └─ Depth 3 ← 最大4階層
└─ Depth 1'
...- 各depthテーブルには固有の [+ Add Menu] ボタン — ポップアップで名前、URLエイリアス、任意のセッション条件を入力。
- 行ごとに: 編集、 削除、矢印で並替。
- 行末のチェックボタンで その 項目の子へ右のカラムに潜り込みます。
ショートコードで差込 — ツリーが揃ったら実ページに落とし込みます。共通include領域(レイアウトフレーム、ヘッダ / サイドバーのpartialなど)に1行あれば十分:
<?php echo get_menus_by_code($project_id, 'group_code', 'nav nav-menu', 'role="navigation"'); ?>
レンダリング時に get_menus_by_code() ヘルパーが project_menu テーブルを読み、最大4階層の <ul>/<li> を組み立てます。session_condition を持つメニュー行は、そのユーザーのセッションが条件を満たすときだけ表示されます。URLが現在ページにマッチする項目には自動で active クラスが付きます。
get_menus_by_code($project_id, 'main') を入れてください。以降のメニュー編集はMenuタブだけで完結し、全ページが即座に反映します。custom_class と custom_attr 引数はデザインテーマのクラス名や属性を渡すので、ヘルパーに触れずに同じメニューがダーク/ライト、サイドバー/トップバーに適応します。
レイアウトビルダー
コードを書かずにブロックを組み合わせてWebページレイアウトを作成。
- {{ item }}
/layout/page を開きます。
- 左サイドバー — [+ 新規ページ] ボタン + 最近 / 共有 / マイページ セクション。
- 上部ツールバー — 検索(フィールド + キーワード)、Block/Frame/Pageの切替タブ、Grid/Listトグル、1ページあたり行数 (20/50/100)。
- 本体 — タイトル、説明、フレーム、デプロイ状況が載ったページカード。
ページカードまたはグリッドアイコンをクリックして 全画面ビルダー を開きます。3つのエリアがあります。
- 左パネル — 上: Frameフィルムストリップ(レスポンシブテンプレート選択)、中央: Frameキャンバス(iframe + スロットオーバーレイ)、下: Blockフィルムストリップ(ドラッグ可能なブロック)。
- 中央パネル — Data sampler(Architecture / Dataタブ) APIバインディング用。
- 右パネル — デプロイ + AIアシスト。
Frameを選ぶと、iframe上に透明なドロップスロットが現れます。Blockフィルムストリップからブロックをドラッグ開始するとスロットが青くハイライト — ドロップでそのスロットにブロックが設置されます。
設置済みスロットは「filled」となり、再度クリックで入れ替え可能。同じブロックを複数スロットに設置したり、1ページで異なるブロックを自由に混ぜたりできます。
中央パネルの Architectureタブ で、各ブロックのサンプルデータキーを実際のAPIレスポンスキーとペアリングします。
- 各ブロックカードの左側に、そのブロックが期待するサンプルキーツリーが表示されます。
- 中央の ⚡(稲妻)トグル でAPIバインディングモードをON。
- 右側で、データベースサービスで作成したエンドポイントを選択 → そのAPIのレスポンスキーツリーが展開されます。
- サンプルキーとAPIキーを クリックでペア — 接続線が引かれ、下部の「Pair Map」に
sample_key → api_keyとして記録されます。
Dataタブでは生のJSONレスポンスがデバッグ用に表示されます。
右パネルでデプロイします。
- Expose parameters — URLに公開するクエリ/パスパラメータのリスト。各行に有効化チェックボックス、名前、ソース(query/path)、デフォルト値。[Add] でリスト追加。
- Deploy URL —
/my-pageのようなスラッグを入力するとプレビューが即時更新。 - [Deploy] — 進捗バーとステップラベルが表示され、完了するとドメインで公開されます。
- その下の Deploy history には過去のURLが蓄積され、いつでも再訪できます。
category をパスパラメータとして公開すれば、同じページコードで /product/beverage と /product/dessert を別データで提供できます — コード重複なし。
スライドショー
プレゼンテーションやディスプレイコンテンツを管理するチャネルサービス。
- {{ item }}
メニューから ディスプレイ > スライドショー を開きます。左サイドバーに [+ スライドショー登録] ボタンと「コミュニティスライドショー」フィルタ。本体はグリッド/リストビュー。
各カードにはタイトル、シーン数、総再生時間、デプロイ状況が表示されます。
[+ スライドショー登録] をクリック。
- ステップ 1 — 紹介: カードとフロー図 (Remote → アップロード → スライドショー → ブラウザ)。URIマッピング、チャネル、67種のトランジション、タイムライン制御を説明。
- ステップ 2 — 登録: タイトル + 説明を入力 → [保存] → 詳細エディタに遷移。
中央の タイムラインパネル で再生を定義します。
- 総時間 — スライダー、10〜3600秒。
- シーン数 — レンジスライダー。シーンごとの時間は自動計算。
- トランジション — 67種のカタログから選択 (fade, slide, cube, page flipなど)。
- [保存] ボタンで確定。
パラメトリックカーソル (Page Sequencer) は、1つのLayoutページから1つのパラメータを変化させてN個のシーンを自動生成します。
- パラメータ名 (例:
month)、アルゴリズム (by_range/by_comma/by_json)、値 (例:1-12ステップ 1)。 - 結果: 月ごと1シーンで12シーンが自動生成されます。
ディスプレイチャネル (MAX限定) — 同じスライドショーを異なるミックスで別ディスプレイに配信。
- チャネル名 (例:「カテゴリA」「カテゴリB」) + 含めるスライドを複数選択。
- 「クエリパラメータを使用」を有効化すると
?keyword=value経由でチャネルをURLにマップします。
右側の デプロイパネル (se-deploy) がショーを公開します。
- URLパス を入力 (例:
/menu-signage) + ドロップダウンから ドメイン を選択。 - [スライドショーをデプロイ] をクリック — 進捗バー、「Deploying...」と「デプロイ完了」メッセージ。
- デプロイ履歴カードにドメイン / パス / タイムスタンプが記録されます。
各ディスプレイのブラウザをそのURLにフルスクリーンで向ければ完了です。
データ収集(パーサー)
ウェブサイトからデータを自動でクローリングしDBに保存。
- {{ item }}
メニューから データ > パーサー を開きます。左サイドバーに [+ 新規パーサールール] と最近 / 公開 / マイルール セクション。本体はグリッド/リストビュー。
各カードに (実行)· (アイテムテスト)· (スケジュール — MAX)· (編集)· (複製)· (削除)アイコン。
[+ 新規パーサールール] で3段階ウィザードが開きます。このウィザードは ルールの基本情報(名前、説明、保存先データセット) だけを登録します — 実際のクロールURL、セレクタ、フィールドマッピングはウィザード終了後に自動で開く パーサー設定画面 で埋めます。
- ステップ 1 — 概要:「パーサールールとは?」の紹介と、4つの機能カード(データ抽出、高度なウェブクロール、フィールドマッピング、再利用性)を横並び、そして「パーサーパイプライン」図(パーサールール → DB / → マクロ → DB / → スケジューラ → DB / → APIエンドポイント → サービス起動)の4経路を一目で。[次へ] で続行。
- ステップ 2 — データベース接続: 抽出行の保存先となる データセットカード をクリック(db_typeバッジ、テーブル名、ドメイン表示)。データセットが未登録なら「Go to Dataset」リンクのみ。[次へ] で3段階デプロイ(「エージェント接続 → パーサーエンジンデプロイ → デプロイ完了」)が自動で走り、選んだdocker agentにパーサーエンジンをプロビジョン。
- ステップ 3 — ルール作成: ルール名と任意の説明を入力し [Create Rule]。基本情報(名前、説明、データセット、共有フラグ)が保存 され、ウィザードが閉じ、作成したルールの設定画面が自動で開きます。
ここでウィザードは終わりです。パーサー設定画面 で対象URL、HTTPオプション、Loop Splitter、XPath/JSONセレクタ、フィールドマッピングを埋め(▶︎ ステップ 3 · 対象URL & 抽出セレクタ 参照)、「テスト」タブで結果を確認して保存 — それでやっと パーサーが実行可能な状態 になります。
上部のステップバーで進捗表示、[戻る] で前ステップへ(デプロイ中は無効)。ウィザードモーダルは右上 [x] のみで閉じます。
(パーサールール編集画面の対象URL設定、Loop Splitter、XPath/JSONセレクタ、後処理関数、AIプロンプトでのルール自動登録の解説です。以下の詳細説明はまだ日本語訳が完了していない部分があります。)
Enter the Target URL at the top of the editor and combine three techniques to extract rows.
- Loop Splitter (3 inputs — primary + 2 secondary) — string patterns that chop HTML into repeated units.
- XPath selectors — up to 3 levels, extracting fields inside each unit. The selector should point at a node set (array), not a leaf value — if the actual data sits at
//h3/a/text(), enter just//h3/aso the result comes out as an array. - JSON selectors — for JSON APIs, dot/bracket paths. Same idea: point at the array path. If the data has a shape like
data.items[0].title, enterdata.itemsas the selector so the item array is produced. - Post-processing functions — chain
trim(@p),replace(...),regex(...),strtoupper(@p),slice(),remove()per column.
The fastest path is to feed a slice of the source (via the Loop Splitter) into the AI Prompt and let the AI response auto-register the rule. Hand-tuning selectors one by one is much slower — especially when the page structure is non-trivial.
Auto-register with an AI prompt (recommended)
Instead of hand-filling selectors, hand the sample to an AI and apply the completed rule it returns.
- Prerequisite — enter the Target URL and run the extract test once from the "Test" tab so a response body exists. That body is injected into the prompt automatically.
- Click the highlighted "AI Prompt" button (wand icon) at the top of the test result panel. A prompt is auto-built in the editor area just below it, picking the right language for the document out of 8 supported (Korean · English · Japanese · Chinese · Russian · German · French · Spanish) and the right document type (HTML / JSON / XML).
- Click inside the editor panel → Ctrl+A → Ctrl+C to copy everything.
- Paste into an AI such as ChatGPT / Claude / Gemini and run → the AI returns a rule JSON.
- Copy the response, then click the "Import Pattern" button (import icon) in the same panel — a paste-in textarea opens. Paste and click [Apply Pattern].
- Loop splitter, selectors, unique key, and every column are mapped into the right slots of the rule automatically; the editor switches to the "fields" tab so you can check the result immediately. A summary toast like "Pattern applied: N fields" appears at the bottom.
If the AI response isn't valid, you'll see an "Invalid JSON" toast and your existing values stay untouched — safe to retry.
カードの (試験管)アイコン またはエディタの 「テスト」タブ でテストモーダルが開きます。
- 上部バー:「N件 / Mカラム」
- エクスポート:CSV · XLSX · JSON · HTML
- グリッド:Row# + 自動判別のカラムヘッダ
- セルhover → 「コピー」ボタン
セレクタを調整してテスト、再調整してテスト — 期待通りになるまで繰り返します。
(ルール一覧カードの ▶(再生)アイコンから開く「実行(Run)モーダル」の使い方 — 3パネル(URLリスト / プラン&実行 / 結果フィードバック)のインターフェース、URI・パーサー・プレビュー・実行方式・ライブ実行フィードバックの各ステップ、期待できる効果。以下の詳細はまだ日本語訳が完了していない部分があります。)
Clicking the (Play) icon on a rule card opens the Run modal — the single screen where you decide where to hit, with what parameter combinations, how to run, and where to store results, then launch and monitor in place.
- [1] URITarget address
{param} tokens
path · query - [2] FuzzerParameter mix
1-N · A,B · DB
combine / pair - [3] PreviewExpand URLs
Fill left panel
Verify count - [4] Run · SaveRuntime / Schedule
DB / CSV / JSON
Items per run - [5] StartFlow checks
[Start] enables
Pause anytime - [6] FeedbackProgress · stats
Per-URL log
Macro chain
Interface at a glance — 3-panel layout
- Left panel · URL list — shows the preview URLs generated from the center panel, numbered. While a run is in progress the current row is highlighted and finished rows show a check, so you can see progress at a glance. Each row has a button to test-parse that single URL in isolation, and a at the top-right loads past run configurations for reuse.
- Center panel · Plan & Execute — the main body: define URI, fuzzer parameters, run/save mode, then launch from the flow diagram's [Start] button.
- Right panel · Result feedback — two tabs. "Results" shows live statistics and log during a run; "Parse Test" shows the cell-level preview when you click on the left.
Step-by-step
- URI input — first card in the center panel. Two example styles — path-token (
/category/{param}/list) and query-string (?param={param}) — are pinned to the header as clickable hint badges. Names inside the curly braces{...}must match the parameter names defined in the next card so substitution works. - Fuzzer parameters — the card that builds the list of values injected into each
{...}. A top toggle picks one of two modes:- Combination — cartesian product of every parameter's values. E.g.
{page}=1..10 ×{cat}=A,B → 20 URLs. - Paired — zip-style: the n-th value of every parameter together. All lists must have the same length.
- Combination — cartesian product of every parameter's values. E.g.
- URL preview — the [URL preview] button at the bottom of the card expands the URI + parameter combinations into real URLs listed in the left panel. The count shows in the header badge, so you can immediately verify the expected size (e.g. range 10 × categories 2 = 20).
- Run mode & Save mode — the third card.
- Run: Runtime (one-off) / Schedule (periodic, MAX plan). Schedule reveals start-time and interval (minutes) inputs inline.
- Items per run: Page / PK.
- Save: DB (dataset, or a custom external DB via host/user/password/database), CSV, JSON, or SQL. DB mode also surfaces table (collection) name and a DBMS badge so you can confirm the destination visually.
- Visual flow guide & Start — below the cards, a small flow diagram chains URI → Parameter → Preview → Save → [Start] → Macro. Each node lights up with a green check as its input is filled. Once required nodes are valid the [Start] button at the top-right activates. (If you pin a macro on the trailing node, it runs automatically right after the scrape.)
- Live feedback while running — the moment you press Start, the top progress bar fills up (parsed / total) and the right-panel "Results" tab updates in real time.
- Stat cards: Total · Passed · Failed · Remaining — the red "Failed" card only appears when a failure actually happens.
- Log view: one line per URL as it's processed, latest highlighted, each showing time · URL · +rows added; failed URLs carry an badge.
- Pause / Resume: the Start button switches to [Pause] during a run — stop at any time safely.
- File-save modes (CSV/JSON/SQL): the Output textarea below fills with the generated file body; a button grabs it immediately.
What this run screen buys you
- Plan, run and observe in one screen — no tab hopping. Tweak the URI, parameter list, or save target and immediately re-run. The configure → run → verify loop is as tight as it gets.
- A fuzzer that scales — generate tens of thousands of URLs without writing one by hand. Ranges, comma lists, DB columns, JSON arrays, newline lists — category × page × date combinations are ready in seconds.
- DB-backed parameters (by_db_field) read a key table column and iterate detail pages on top of it — the classic "list → detail" two-stage crawl works end-to-end without spreadsheets or glue scripts.
- Transparent live feedback — per-URL checkmarks, streaming log, and success/fail counters make it easy to spot exactly where things stalled. Rerun a failed row on its own via to isolate the cause.
- Resource-friendly architecture — the actual HTTP and parsing runs on your docker agent, not the QuickStart server. Large crawls don't affect the service's bandwidth.
- Macro chaining — attach a macro to run right after the scrape for notifications, aggregation, or post-processing, turning collect → clean → notify into a single action.
(スケジュール実行(MAX限定)のカード構成、5段階のフロー図、データベースエディタでの結果検証、マクロと連鎖するTipなど。以下の詳細はまだ日本語訳が完了していない部分があります。)
Scheduled runs are a hands-off mode: the docker agent executes the rule on a fixed interval on its own, even while the screen is closed. Rows flow straight into the dataset (DB), so to actually see the results you open the target table in the Database editor.
- [1] Schedule setupStart time
Interval (min)
Active toggle - [2] Agent sync[Save] pushes
config to the
docker agent - [3] Auto periodic runAgent runs alone
QuickStart idle
Background task - [4] DB accumulationRows INSERT into
dataset table
Dup keys skipped - [5] Check in Database editorData > Database
Open the table
Query with WHERE/ORDER
The (clock) icon on a card opens the schedule modal (FREE/PRO plans show a "Max" ribbon).
- Start time (hour 0–23, minute 0–59)
- Interval (minutes)
- Active toggle
- Run mode: Single URL / URL list (batch)
[Save] persists to QuickStart and auto-syncs to the selected docker agent. The agent is what actually runs the schedule — QuickStart never sits in the traffic path.
Verify results in the "Database editor"
Because scheduled runs are headless, the way to check the output is to open the target dataset directly and inspect the rows that piled up.
- Open Data > Database from the left menu.
- Click the dataset card that the parser rule is linked to — this opens the Database editor.
- Pick the target table from the left table list (e.g.
items,products, etc.). - Use WHERE / ORDER BY at the top to bring recent rows to the top (
ORDER BY created_at DESC,ORDER BY id DESC) and inspect what the last scheduled run added. - A quick row count (COUNT) or a date-range filter is enough to sanity-check trend — if the count grows each interval, the schedule is healthy.
The run log itself is shown as a table in the Run modal's right-panel "Results" tab when schedule mode is active, but for content verification of the actual harvested data, the Database editor is always the source of truth.
自動化マクロ
繰り返し作業を自動化するサーバーサイドスクリプトを作成・実行。
- {{ item }}
メニューから データ > マクロ を開きます。左サイドバーに「最近」「コミュニティ」「マイマクロ」セクション、本体はグリッド/リストビュー。上部ツールバーで名前または説明による検索ができます。
サイドバーの [+ 新規マクロ] ボタンで作成ウィザードが即座に開きます。
[+ 新規マクロ] で 4段階ウィザード が開きます。このウィザード1つで、マクロの基本情報登録と 実行サーバー準備 を両方カバーします。
- ステップ 1 — マクロ紹介: 「マクロとは?」の紹介と4つの機能カード(パイプライン連鎖、アダプタパターン、入力 → 出力、コード生成)、4つのトポロジーを示すフロー図(DBクエリ・連鎖・パーサー・スケジューラ)。入力なし — [次へ] を押すだけ。
- ステップ 2 — 接続方法: 実際にマクロが動く場所を準備します。2つのオプション:
- 新規マクロサーバーをデプロイ — Railwayアカウント接続(トークン貼付)後、言語・フレームワーク・コアスタック・任意のアドオン(MongoDB / FFmpeg / Puppeteer / WebSocketなど)・DB認証情報を選択。[サーバーデプロイ] をクリックすると6段階パイプライン(Receive → Decrypt → Dockerビルド → Deploying → Network → Verify)が走り、あなたのアカウントに専用のマクロランタイムが用意されます。
- 既存マクロサーバーに接続 — すでにマクロコードが動くサーバーがあるなら、接続情報を入れてそこに繋ぎます。
- ステップ 3 — タイプ選択: 24種のマクロタイプ(ETLパイプライン · バッチAPI · データマイグレーション · CSV/Excelインポート など)から1つ選択。タイプに合ったスターターコード(入力パラメータ、ループ骨組、出力構造付き)が次ステップのスタート地点として 自動生成 されます。
- ステップ 4 — 登録: マクロ名(例「夜間DB同期」「一括翻訳」)と短い説明を入力し [作成]。マクロが保存され、ウィザードが閉じ、詳細ビュー(コードエディタ)が自動で開きます。
上部のステップバーで進捗が追え、[戻る] で前のステップに戻せます(デプロイ中は無効)。ウィザードは右上 [x] ボタンでのみ閉じます。
ウィザードが閉じると 3ペインエディタ が開きます: 左は 入力フィールド定義、中央は PHP / Node.js / Python タブの コードエディタ、右は AI Prompt ペイン。ステップ3で選んだマクロタイプ用の スキャフォルド があらかじめ埋められているので、必要な所だけ編集します。
- [1] run_data 受信input_data
conn_string
table_name · user_id - [2] 入力の正規化array → object
型変換
デフォルト - [3] コアロジックAPI · DB
ファイル · shell
データ変換 - [4] 結果組立success フラグ
data / json
download_links - [5] Returnウィザードで選んだ
出力タイプに合わせる - [6] AI Prompt右パネル
シナリオ選択
AI → コード貼付
自動で受け取る変数 — run_data
関数は常に run_data という1つの引数を取ります。サーバーは実行直前にこれを埋め、最低限以下のキーを含みます。
run_data.input_data— Quick Testまたはスケジューラにユーザーが入れた値。最初は{ item_name, item_value, item_type }の配列 として届くので、マクロの最初の仕事はプレーンなキー/値オブジェクトに変えることです。run_data.conn_string— ウィザードで選んだデータセットのDB接続文字列(サーバーでAES復号済み)。DB系マクロはそのまま使います。run_data.table_name,run_data.file_name— ウィザードの対象テーブル / ファイル名。run_data.user_id,run_data.app_id— 呼出元とマクロID。ロギングや権限チェックに便利。run_data.save_type,run_data.app_type— ウィザードで選んだ保存モードとマクロタイプ。分岐に使用。
推奨コーディングパターン
趣味開発者でもそのままコピー可能な最小骨格。ウィザードで設定した 関数名(例: macro_run)を変えないでください — サーバーはその名前で呼び出します。
Node.js 例 — 実際の _sample/code39.js から抽出:
async function macro_run(run_data) {
// ── 1) 入力の正規化 — 配列でもオブジェクトでも受付 ──
const raw = run_data.input_data || {};
const params = {};
if (Array.isArray(raw)) {
raw.forEach(f => { params[f.item_name] = f.item_value; });
} else {
Object.assign(params, raw);
}
// ── 2) デフォルト · 型キャスト ──
const output_format = params.output_format || 'svg';
const style = params.style || 'default';
const max_items = Number(params.max_items || 10);
// ── 3) コアロジック ──
try {
// ... API呼び出し、DBクエリ、ファイル変換など
const results = [ /* 集めた結果 */ ];
// ── 4) 結果組立 & return(成功) ──
return {
success: true,
data: results, // 配列はテーブルとして描画
message: results.length + ' 件処理しました',
};
} catch (e) {
// ── 4') 失敗も同じ形 ──
return { success: false, error: e.message, data: [] };
}
}PHP / Python も同じ形 — 関数が run_data を取り、['success' => true, 'data' => [...]] / {'success': True, 'data': [...]} を返します。左のInputペインでフィールド定義後、中央の スキャフォルドボタン(中央ペインヘッダ)を押すと、定義した各フィールドを展開した言語別骨格が自動生成されます。
returnは「ウィザードで選んだ出力タイプ」に合わせる
返却オブジェクトは標準プロトコルに従いますが、どのフィールドを埋めるかはStep 3(作成ウィザード)で選んだ出力形態が基準です。Quick Test結果パネルはこのフィールドを見て描画方式を決めます。
success: true/false(必須 · すべてのマクロ共通)data: [{...}, {...}]— 出力タイプが「表/テーブル」のとき。配列を渡すと結果パネルが列を自動判別して テーブル として描画。json: {...}— 出力タイプが「JSON / 原文」のとき。オブジェクトをそのままJSONビューア(textarea + コピーボタン)で描画。download_links: [{ url, name, size }]— 出力タイプが「ファイルダウンロード」のとき。ダウンロードボタンリストとして描画。message(成功)/error(失敗) — テキストブロック(<pre>)。どんな出力タイプでも補助として併用可。
複数フィールドを同時に埋めてもOK — data でテーブルを出しつつ download_links でCSVも配る、といった組合せ可能(実際のサンプル code39.js は data + download_links + message を一緒に返します)。
AIプロンプトでコードを得る — 右ペイン
ロジックが複雑だったり外部ライブラリの使い方が不慣れなときは、右側の 「AI Prompt」 ペインで支援を求めます。
- まず 左のInputペイン で必要な入力フィールド(名前・タイプ・説明)を定義。これがプロンプトに自動で含まれます。
- 右ペイン上部の シナリオバッジ(マクロタイプに合わせた例題リスト — 「指定URLをスクレイピングしてDBにINSERT」「テーブルA→B マイグレーション」など)をクリックすると、そのシナリオテンプレが プロンプトtextareaに自動入力されます。
- textareaで詳細要件(どのURL、どのカラム、どの例外処理など)を自由に追加。
- ヘッダの コピーボタン でプロンプト全体をコピー → ChatGPT / Claude / Gemini に貼って実行。
- AIが返したコードを 中央エディタ に貼って 保存。
- そのままStep 4(Quick Test)に進んで反復改善。
スキャフォルドボタン()で出した空の骨格 + AIプロンプトの組合せを活用すれば、実際に書くべきコードは コアロジックの数行だけ に絞り込めます。
console.log(params) / print($input_data) で実際の受信値を確認できます — 下のターミナルペインにそのまま流れます。
左ペイン上部の Quick Test タブ(🧪 フラスコアイコン)に切替。Quick Testはステップ2で準備したマクロサーバーでコードを走らせます。
- 入力パラメータを行単位で埋めます。
- [実行] をクリック → 「実行中...」スピナー。
- 返却の形に応じて結果表示が変わる:
data→ テーブルjson→ JSONビューアdownload_links→ ダウンロードボタンリストmessage/error→<pre>テキストブロック
stdoutとstderrは下のターミナルペインにリアルタイムで流れます — デバッグに便利。
success 忘れです。
Quick Testが良好に動いたら、無人実行用にマクロをスケジュールに渡します。詳細ビューの スケジュールセクション で必要なのは2つの値だけ。
- 開始時刻(オフセット) —
HH:MM形式(例:00:00= 真夜中、03:30= 午前3:30)。繰返しスケジュールのアンカー。 - 間隔 N(分) — 開始時刻から N分おき にマクロが走ります。
5で5分ごと、60で毎時、1440で1日1回。 - 有効化トグル — 設定を保ったまま一時停止 / 再開。
例: 開始時刻 00:00 + 間隔 5 → 真夜中から5分おき(00:00, 00:05, 00:10 …)。開始時刻 09:00 + 間隔 1440 → 毎日午前9時に1回。
保存すると、マクロサーバーがこの周期で自分でマクロを走らせます。QuickStartはシグナルのみ — 実行とトラフィックはマクロサーバー上に存在します。(cron式はなく、開始時刻 + 間隔だけでスケジューラは動きます。)
データベース
データベースの作成・管理とREST API自動生成。
- {{ item }}
メニューから データ > データベース を開きます。左サイドバーに青い [+ 新規データセット] ボタンと最近 / 公開 / マイ / チームのセクション。本体はグリッド/リストビューのカード。
各カードに4つのアイコン: ▶(DBエディタ)· テーブル(セルエディタ)· (API設定)· コピー/削除。
[+ 新規データセット] → ウィザードモーダル。
- ステップ 1 — 3つの接続オプション: 新規DBをデプロイ(Railway)· 既存DBに接続 · ローカルファイル(JSON/CSV/Excel)。DBタイプドロップダウン(MySQL 3306 · MariaDB 3306 · PostgreSQL 5432 · MongoDB 27017)・ホスト・ポート・DB・ユーザー・パスワード → [接続テスト] で認証情報がDBに到達するか検証。
- ステップ 2 — 接続成功したらテーブルを選び、フィールドが展開されます。
- ステップ 3 — データセットを登録: 名前・説明・テーブル・PK・カラム(
*かコンマ区切り)・WHERE・LIMIT・ORDER BY・shared。右パネルの [クエリテスト] で結果プレビュー、[保存]。
データセットカードの ▶(再生)アイコン で全画面エディタを開きます。3パネル構成です。
- 左 — タブ(Tables/Views/Procedures/Functions)、テーブル構造インスペクタ、コマンドアイコン(CREATEコピー · Drop · Update · Insert · Delete · Join · Reverse · Refresh)。
- 中央 — マルチタブSQLエディタ。▶ Run か F5/F9。TSV/CSV/JSON/SQL でエクスポート、または「マクロへ送信」で直接マクロへ。
- 右 — セル単位で編集可能な結果グリッド。
カードの API設定ボタン(プラグアイコン)をクリックするとAPI設定モーダルが開きます。
- 基本: ネームスペース(必須、URL末尾)・テーブル・JOINテーブル・ページ変数(既定
page)・1ページあたり(50)・キャッシュ(0〜1440分)。 - [自動生成] → JSON形状を組み立てます(main_container → main_fields → item_container → item_fields → detail)。各フィールドは「JSONキー → SQL変数」ペア。
- [保存] → [デプロイ] でエンドポイントが有効化されます。
エンドポイントは GET https://happycat.apidealder.net/endpoint/{namespace} で公開されます。モーダルの ACLセクション で保護します。
- APIキー(自動生成ボタン · header/param 渡し · ヘッダ名
X-API-KEY) - IPホワイトリスト — ワイルドカード / CIDR
- Referer制限 — 許可ドメイン
- レートリミット — 分あたり最大リクエスト
例: curl -H "X-API-KEY: ..." https://happycat.apidealder.net/endpoint/menu_list
リモート管理
デプロイ済みサーバーのファイルをブラウザから直接開いて編集できます。FTP や SSH クライアント不要で、フォルダ閲覧・コード編集・アップロード・ターミナルまで一画面で完結します。
- {{ item }}
リモート管理は4つのゾーンに分かれています。クリックし始める前に、どこを見ればよいかを把握しておきましょう。
- 左側のサーバーリスト — 管理中のドメインが小さなステータスドット付きで一覧されます。画面を広く使いたい時はアイコンのみに折りたためます。
- 中央のファイルエリア — 選択中のサーバーのファイルブラウザ。上部のツールバーはパスバー、ソートボタン、ターミナルトグルを含み、下部のフォルダ内容は深く潜るほど右にカラムが増えていきます。
- 下部のアクションバー — アップロード · 新規フォルダ · 新規ファイル · ダウンロード · 削除。ファイルかフォルダを選んだ後だけボタンが有効化されます。
- ターミナルパネル — 必要な時に下からスライドアップするコンソール。上部ツールバーのターミナルアイコンで表示/非表示を切替えます。
左側リストからドメインをクリック。ドメイン名の隣のドットが現在の状態を示します:
- 緑ドット — オンライン。ファイル一覧がすぐ開きます。
- 灰ドット — オフライン。コンテナがスリープ中か、ネットワークがブロックされている可能性があります。
- 白ドット — チェック中、または状態不明。
リストが空なら「まずサーバーをデプロイしてください」と表示され、Single File / プロジェクト / データベースのデプロイ画面へのショートカットボタンが並びます。
中央エリアは カラム型ブラウザ で、フォルダをクリックするたびに右側に新しいカラムが開きます。同時に表示できるのは最大4カラムまでで、さらに深い階層に行くと一番左のカラムが自動で畳まれます。
- パスバー — ハウスアイコンでルート (/) に戻り、スラッシュで区切られた各セグメントをクリックすればそのパスに直接ジャンプできます。
- パス入力 —
/var/www/html/storage/logsのようにフルパスを入力し Enter を押すと、クリックせずに直接そこへ移動します。 - ソートボタン — 名前 · サイズ · 更新時刻。同じボタンをもう一度押すと降順/昇順が入れ替わります。
- 選択 — シングルクリックで1件選択、Shift+クリックで範囲選択、Ctrl/⌘+クリックで個別に追加/解除。複数選択状態になるとアクションバー右上に「N件選択中」バッジが出ます。
ファイルをワンクリックで選択。もう一度クリックすると開きます — ファイルタイプに応じて右ビューが自動で起動します。
- テキスト/コードファイル → 構文ハイライト付きエディタが中央に開きます。HTML、PHP、Vue、CSS/SCSS、JavaScript/TypeScript、JSONなどを自動判別します。
- 画像(PNG · JPG · GIF · SVG · WebP · BMP · ICO) → プレビュービューアで開いて視覚的に確認できます。
- バイナリ/実行ファイル は「バイナリファイルは編集できません」と表示され開きません。
- エディタ右上の [保存] ボタンはその場で変更をサーバーに反映 — 再デプロイ不要。Esc または [キャンセル] で保存せずに閉じます。
- エディタで開けるのは 10MBまで のファイルのみ。それ以上は「ファイルが大きすぎます」と表示されます。
.env や設定の微調整、ログ確認のような本番の小さな修正はここで直接編集するのが最速です。保存した瞬間に反映され、再デプロイは不要です。
下部アクションバーとターミナルパネルを組み合わせて実作業を進めます。
- アーカイブアップロード — ドラッグまたはクリックで .zip · .tar · .tar.gz · .tgz ファイルを選択。アーカイブ内容のプレビューが表示され、Start Upload を押すと1MBチャンクで送信され進捗バーが表示、完了時に現在フォルダが自動リフレッシュされます。
- ファイルアップロード — 1つまたは複数のファイルを選び、そのまま現在フォルダにアップロード(解凍なし)。
- 新規フォルダ / 新規ファイル — 名前を尋ねられます。使える文字は英数字、ドット、ハイフン、アンダースコアのみ。
- ダウンロード — ファイルはそのまま、フォルダを選ぶと自動でZIPに固めて1ファイルとして取得されます。
- 削除 — 1回だけ確認あり。複数選択時は一括で処理されます。
- 移動 / コピー — ファイルをフォルダにドラッグすると確認ダイアログが開きます。または Ctrl+X/Ctrl+C で選択をストックし、別フォルダで Ctrl+V して同じ確認ダイアログでペーストできます。
- ターミナル — 上部ツールバーのターミナルアイコンで下部パネルがスライドアップし、選択中サーバーのシェルに接続されます。コマンドを入力して Enter — stdoutは白、stderrは赤で表示。↑/↓ で過去のコマンドを呼び戻せ、現在の作業ディレクトリは追跡されるので、
cd some/pathの後はそこから続けて実行されます。
/bin/sh(bashではありません)。新しいパッケージは apk add パッケージ名 でインストールしてください。
AIプロンプトガイド
QuickStartはAIを内蔵して直接問い合わせる方式ではありません。代わりに、画面の各所に配置された AIプロンプト ボタンがその場のコンテキスト(テーブルスキーマ・HTMLサンプル・レイアウト構造など)を構造化プロンプトとしてまとめてクリップボードにコピーします。ChatGPT・Claude・Gemini などの外部AIに貼り付け、返ってきた応答は隣の 取り込み ボタンでUIに自動反映されます。プロンプトはすでにタスクに合わせてスキャフォールディングされているので「何をどう説明するか」で悩む必要はありません。
VSCode拡張
QuickStartプロジェクトを自分のPCで快適に扱うためのVS Code拡張です。Webコンソールで作ったプロジェクトをパッケージとしてダウンロードし、フォルダをVS Codeで開くだけで、自動認証 → Laravel/フロントエンド環境の自動準備 → ファイル編集 → 他サーバーへのデプロイ → Webとエディタの双方向同期まで、すべてが下部パネルのQUICKSTARTビュー内で完結します。一度だけ以下の手順をなぞれば、あとはボタン操作で済みます。
40言語翻訳
一つのプロジェクト内にあるすべての画面文言(単語・メニュー名)を一度に複数言語へ翻訳するためのツールです。プロジェクトのページから翻訳対象を自動収集し、AIに渡すプロンプトを組み立て、AIの応答をグリッドに自動反映し、プロジェクト単位の翻訳ストア(project_translateテーブル)に保存、最終的にLaravel用のlang_files.jsonとして書き出します。目標は1サイクルで最大40言語まで拡張すること — 初めての人でも以下の手順をなぞるだけで大丈夫です。
ソリューションマーケット
他のユーザーが作ったプロジェクト・マクロ・シングルファイルを検索してForkし、自分用の出発点にできます。
- {{ item }}
Fork & 共有
プロジェクトを共有したり、他人のプロジェクトをForkして素早くスタート。
- {{ item }}
ドメイン管理
QuickStartが提供する無料ドメインを管理。
- {{ item }}
初めてのウェブサイトを作る
ポートフォリオサイトを例に、ウェブサイトを最初から最後まで作る全工程を案内します。
サインイン後、上部ナビゲーションまたはダッシュボードから サービス → Single File を開きます。画面は上部ツールバーと本体に分かれています:
- 上部ツールバー — 左側:履歴 · ガイド · タイトル入力 · 保存 (💾)。中央: テンプレートドロップダウン。右側:共有 · 実行 ▶ · デプロイ 📦。
- 中央エディタ — 上部に4つのタブ:
prompt · html · scss · vuejs。クリックで切替。 - 右側プレビューパネル — 実行ボタンを押すとレンダリングされます。
ツールバー中央のテンプレートドロップダウンを開き、「Restaurant Booking System」を選びます。順番は:
- ドロップダウンの値が変わった瞬間、選んだテンプレートが自動で適用されます。
- 4つのタブ(prompt · html · scss · vuejs)に構築済みコードと、再生成に使うAIプロンプトが自動で埋められます。
- アクティブなタブはデフォルトで prompt に切り替わります — このテキストは、再生成を依頼するときAIが使うものです。
- ツールバーの 実行 ▶ を押すと、右側プレビューに3カラムの予約画面(カレンダー / 時間スロット / 予約フォーム)がレンダリングされます。
メモ:このテンプレートは店のオーナーが日付・時間スロット・テーブル空きを管理するための 運営画面 であって、単純な来店者向けメニューランディングページではありません。
このテンプレートは2層でカスタマイズします:コード不要の 設定モーダル と 直接のコード編集。エントリポイントはレンダリングページ右上のテーマ切替 (☀/🌙) の隣にある ⚙ 設定 アイコンです。
A. 設定モーダル — データのみ、コード不要
- ⚙ をクリック → 全画面オーバーレイで中央にモーダル(4タブ)が開きます。
- Time Ranges — 朝 / 昼 / 夜の開始・終了時刻を数値入力で調整。上部のビジュアライゼーションバーに色分けされたセグメントがリアルタイムで反映されます。開始==終了だと「(無効)」と表示されます。
- Time Slots — ステップ (10 / 30 / 60 / 120分) を選び、グリッド内のスロットを個別にアクティブ/非アクティブ切替。上部にアクティブ/非アクティブ件数が表示されます。
- Tables — 行内リネーム + 削除のリストと、下部の入力でテーブル追加。このリストが予約フォームの「テーブル」セレクトを駆動します。
- Holidays — 繰り返しの休業日(日〜土、7つのトグルボタン)+特定の休日(日付入力 + 理由テキスト、追加/削除リスト)。理由は設定内でのみ表示され、公開画面には出ません。
B. コード編集 — 店名、テーマなど
- html タブ — ヘッダのタイトル文字列
"レストラン予約"をあなたの店名に置換。Ctrl+F で位置検索できます。 - vuejs タブ —
mounted()にモックデータ生成(D+1 ~10%、D+2 ~5%、D+3 ~2% のランダム予約 + 韓国名の配列)が入っています。実利用時はそのブロックを空にするかサーバAPI呼び出しに差し替えてください。祝日はhttps://date.nager.at/api/v3/PublicHolidays/{year}/KRから取得します。必要ならKRを他の国コードに変えてください。 - scss タブ — テーマはSCSS変数ではなく CSSカスタムプロパティ を使っています。
.reservation(ライト) /.reservation.dark(ダーク)の下に定義:--primary(ブランドアクセント)、--bg(ページ背景)、--card-bg、--text/--text-sub、--border、--holiday(祝日の赤)、--closed-bg(店休日のアンバー)、--occ-bg/--occ-border(残席ありのスロット)。ここだけ編集すれば見た目全体が一貫して変わります。
編集後: 保存 (💾) → 実行 ▶ で更新。未保存のタブには小さなドット (●) が表示されます。
mounted() で localStorage 読み込みと変更を保存するウォッチャを追加するか、実DBに保存するProjectサービス (PRO) にステップアップしてください。
ここで 自分で予約を一件やってみます。お客様として動く感覚で。これは公開後にスタッフや来店者が実際に行う操作そのものです。プレビュー内で次の順番で進めます:
- カレンダー(左側)で日付を選ぶ — 今日以降の任意の日付をクリック。赤い日は祝日、アンバーは自分で設定した特定休業日、グレーアウトは定期休業日でクリックできません。既に予約がある日には「+2」のような小さな数字が角に表示され、予約件数がひと目で分かります。
- 時間を選ぶ(中央) — 日付を選ぶと、利用可能な時間が丸いボタンとして現れます。ボタン上の「2/5」は「5テーブル中2件予約済み」の意味。薄い色=余裕あり、濃い色=ほぼ埋まっている、取消線=満席でクリック不可。
- 既存予約を確認 — 時間ボタンをクリックすると、その時間の既存予約リスト(お客様名、テーブル、人数)が下に開きます。重複予約を防ぐためです。
- フォームを入力(右側) — 選んだ日付と時間がフォーム上部にサマリ表示されます。上から順に埋めます:
- お客様名
- 電話番号:数字だけ入力すると「010-1234-5678」形式に自動整形
- テーブル:その時間に既に埋まっているテーブルは 自動で非表示 になるので、間違って重複予約することがありません
- 人数:1〜20名
- メモ:特別なリクエスト(誕生日、車椅子対応など)
- [予約する] ボタンをクリック — 名前が空なら警告が出ます。そうでなければ「予約完了」の確認が出て、カレンダーの「+N」と時間ボタンの「N/M」が即座に1増えます。フォームは自動でクリアされ、次の予約に備えます。
- ライトとダーク両方のテーマを試す — 右上の ☀/🌙 アイコンをクリック。店は明るい日中にも薄暗い夜にも使われるので、両方できちんと読めることを確認してください。
スマホとタブレットの表示を確認するには、ブラウザウィンドウをマウスで細く引き絞ってください。画面が狭くなると3カラムが自動で2カラム → 最終的に1カラムにスタックします。スタッフはタブレット、お客様はスマホを使うことが多いので、狭い画面でもテキストとボタンが十分大きくタップしやすいことを確認してください。
デプロイはホスティングプロバイダのRailwayを使います。Deployボタンを初めて押したとき「Railwayアカウントを接続」モーダルが表示されます。順番は:
- Log in with Railway をクリック → Railwayのログインページが新しいタブで開きます。
- Railwayアカウントがまだですか?そのページで無料登録(メールかGitHub)。
- 「QuickStartがデプロイ権限を要求」画面で Authorize をクリック。
- QuickStartにリダイレクトされ、「接続しました」トーストが表示されます。
この手順は一度だけ。以降のデプロイではスキップされます。
アカウント接続後、再び Deploy をクリック。進捗モーダルが開き、8ステージを順に進みます — 完了するごとに緑になります。
- Pack — コードをパッケージにまとめる。
- Upload — パッケージをRailwayに送信。
- Install — 必要なライブラリをインストール。
- Build — SCSSをコンパイルしVueをバンドル。
- Migrate — 静的ファイルをWebサーバの配置先に配置。
- Start — コンテナを起動。
- Health — サイトが実際に応答するか検証。
- Complete — URLを確定して付与。
合計で通常1〜3分。モーダル下部の ログを表示 を展開するとリアルタイムで見られます。
デプロイが完了するとモーダル下部に ドメインを開く ボタンが現れます。クリックすると自動で割り当てられた無料ドメイン(例: happycat.apidealder.net)が新しいタブで開きます。そのURLを誰とでも共有できます。
後で自分のドメイン(例: myname.com)を紐づけるには、ダッシュボードの 設定 → ドメイン管理 でカスタムドメインを登録し、表示されたDNSレコードをDNSプロバイダに追加します。
APIサーバーを構築
REST APIサーバーを作り、フロントエンドからデータを読み込む流れを案内します。
上部ナビまたはダッシュボードから サービス → データベース をクリックしてデータベースページを開きます。画面は左サイドバーと中央本体に分かれています。
- 左サイドバー — 上部に青い [+ 新規データセット] ボタン、その下に「最近」「公開データセット」「マイデータセット」「チーム」のセクション。
- 中央本体 — 上部ツールバーには検索ボックス(名前 / テーブル / URI)、グリッド⇄リストの表示切替、1ページあたり行数セレクタ(20/50/100)。その下に既存のデータセットがカードで並びます。
- 各カードの4つのアイコン — ▶(再生)はデータベースエディタを開く · テーブルアイコンはセルエディタを開く · API設定ボタン(プラグアイコン)はAPI設定を開く · さらにコピー/削除。カード名をダブルクリックでインラインリネーム。
左サイドバーの [+ 新規データセット] をクリックすると、中央に 3段階ウィザードモーダル が開きます。流れは:
- ステップ 0 — 概要: データセットの説明と機能紹介カード。Next で進む。
- ステップ 1 — 接続方法: 3つの大きな選択肢から1つ。
- 新規DBをデプロイ — Railway上に新しいDBコンテナをプロビジョニング。
- 既存DBに接続(最も一般的) — 既にお持ちのDBに接続。
- ローカルファイル — JSON / CSV / Excelをデータセットとしてアップロード。
- 「既存DBに接続」の場合:
- DBタイプ ドロップダウン — MySQL(デフォルトポート3306)· MariaDB(3306)· PostgreSQL(5432)· MongoDB(27017)。選ぶと既定ポートが自動入力。
- ホスト · ポート · データベース名 · ユーザー · パスワード
- 下部の [接続テスト] をクリック — 成功すると自動でステップ2へ、失敗すると下に赤いエラーが出ます。
接続できたら、ウィザードは自動で残り2ステップを案内します。
ステップ 2 — テーブル選択
- DB内のテーブルが行(名前 · アイコン · 行数 · コメント)で表示されます。
- テーブルをクリックすると、右パネルが展開され フィールド一覧 が表示されます。
ステップ 3 — データセット登録(ここで「データセット」メタデータを確定)
- 左 — 登録フォーム:
- データセット名 (必須) — 例「メニュー一覧」
- データセットの説明
- 対象テーブル ドロップダウン (必須)
- 主キー —
idがあれば自動選択。 - 含めるカラム —
*(全て)またはid,name,priceのようなコンマ区切り - WHERE句 — 例:
stock_flag = 1 - LIMIT — 例:
0,100(オフセット0、100行) - ORDER BY — 例:
created_at DESC - 共有チェックボックス — 他ユーザーに読み取り専用で公開。
- 右 — クエリテスター: [クエリテスト] をクリックすると現在の設定で実際のSQLが実行され、結果の行数・カラム数・ライブプレビューが表示されます。望む結果になるまで左側の条件を調整。
- [保存] をクリック → ウィザードが閉じ → メイン画面に新しいデータセットカードが現れます。
データセットカードの ▶(再生)アイコン をクリックすると、データベースエディタ が全画面オーバーレイで開きます。3パネル構成です。
- 左 — オブジェクトブラウザ: 上部タブ(Tables / Views / Procedures / Functions)。任意のテーブルをクリックすると下のインスペクタにカラム · 型 · コメントが表示。リスト上のコマンド帯には CREATE スクリプトコピー、Drop、Update、Insert、Delete、Join、Reverse、Refresh。
- 中央 — SQLエディタ: 複数クエリをタブ管理。タブをダブルクリックでリネーム。ツールバーに ▶ 実行ボタン と F5 / F9 ショートカット。結果は TSV / CSV / JSON / SQL でエクスポート可、または「マクロへ送信」で直接マクロへ。
- 右 — 結果グリッド: 直前のクエリの行。セル単位で編集可能。
このステップで これから公開するデータが本当に望み通りか を確認します。合わなければここで先に修正してください。
UPDATE ... WHERE id=... をSQLタブで明示的に書く方が安全で、履歴も追いやすくなります。
このデータセットをREST APIとして公開します。データセットカードの API設定ボタン(プラグアイコン)をクリックして API設定モーダル を開きます。
- 基本情報
- ネームスペース (必須) — URL末尾になります。
menu_listは/endpoint/menu_listになります。 - テーブル — 対象テーブル(データセットから自動入力)
- JOINテーブル — JOINしたい場合の追加テーブル(任意)
- ページ変数 — ページングのクエリパラメータ名(デフォルト
page) - 1ページあたり — デフォルト 50
- キャッシュ時間 — 0〜1440分
- ネームスペース (必須) — URL末尾になります。
- レスポンスの自動生成: [自動生成] をクリックすると
main_container → main_fields → item_container → item_fields →(任意)detailの形でJSON構造が組み立てられます。各フィールドは「JSONキー → SQL変数」のペア(例:name → $customer_name)。手動で追加・削除も可。 - アクセス制御(ACL) — 下に詳述。
- [保存] でAPI定義を保存。
- [デプロイ] でデプロイパイプラインを実行 — プログレスバーが表示され、完了するとエンドポイントが公開されます。
デプロイ完了後、エンドポイントは次のURLで公開されます(カスタムドメイン使用時):
GET https://happycat.apidealder.net/endpoint/menu_listGET https://happycat.apidealder.net/endpoint/menu_list?page=2GET https://happycat.apidealder.net/endpoint/menu_list/csv— CSVダウンロード
APIキー認証(APIモーダル内のACLセクション):
- APIキー — [自動生成] でUUID形式のランダムキー。
- 受け渡し —
headerまたはparam。 - ヘッダ名 例:
X-API-KEY/ パラメータ名 例:api_key。
呼び出し例
ヘッダ経由:
curl -H "X-API-KEY: your-secret-key" https://happycat.apidealder.net/endpoint/menu_list
クエリパラメータ経由:
curl "https://happycat.apidealder.net/endpoint/menu_list?api_key=your-secret-key"
ブラウザfetch:
const res = await fetch('https://happycat.apidealder.net/endpoint/menu_list', { headers: { 'X-API-KEY': 'your-secret-key' } });
const data = await res.json();
追加のガード(すべてACLセクション):
- IPホワイトリスト — ワイルドカード(
192.168.1.*)、CIDR(10.0.0.0/24)対応。 - Referer制限 — 許可ドメインのリスト。
- レートリミット — 1分あたりの最大リクエスト数。
データ収集を自動化
ニュースサイトから記事を自動収集しDBに保存するパイプラインを作ります。
上部ナビまたはダッシュボードから サービス → データ収集 をクリックしてパーサールール一覧画面を開きます。レイアウトはデータベースページと同様です。
- 左サイドバー — 上部に青い [+ 新規パーサールール] ボタン、その下に「最近」「公開ルール」「マイルール」(ユーザーフィルタ付き)。
- 中央本体 — 検索、グリッド/リスト切替、ページネーションのツールバー。下に既存ルールがカード(またはテーブル行)で並びます。
- 各カードのアイコン — ⚗️(試験管)アイテムテスト · ⏱(時計)スケジュール(プランに含まれないと「Max」リボン表示)· 編集 · 複製 · 削除。カードにはルール名、テストページ、説明、作成日が表示されます。
左サイドバーの [+ 新規パーサールール] をクリック → 3段階ウィザード が開きます。
- ステップ 1 — 概要: 4つの情報カード(抽出 / クロール / フィールドマッピング / 再利用)とパイプライン図(パーサールール → データベース / マクロ / スケジューラ / API)。入力なし、コンテキストのみ。
- ステップ 2 — データベース接続: 収集結果の保存先となる データセット をカードリストから選びます。各カードにはデータセット名、DBタイプ、テーブル、ドメインが表示。選択後 [次へ] を押すと「エージェント接続 → パーサーエンジンデプロイ → デプロイ完了」の3段階自動フローが走り、選んだdocker agentへパーサーエンジンがインストールされます。
- ステップ 3 — ルール登録:
- ルール名 (必須) — 例「Naverニュース IT セクション」
- 説明 — 何を収集するかを一行で
- [ルール作成] をクリックするとウィザードが閉じ、そのままパーサー設定画面に遷移します。
ルールエディタが開き、上部に 対象URL フィールドが表示されます。スクレイピングしたいページ(例: https://news.example.com/it)を入力し、抽出を設定します。パーサーは3つのアプローチを組み合わせます。
- Loop Splitter(3入力 — メイン + 補助2つ) — HTMLを反復単位に切る文字列パターン。例:
<li class="article">の一部をスプリッタにすれば各記事が1アイテムになります。 - XPathセレクタ(最大3レベル) — 各反復単位の中からタイトル / URL / 画像をXPathで取り出します。値は ノードセット(配列) を指すべきなので、
//h3/a/text()の位置にデータがあるなら//h3/aとだけ指定。 - JSONセレクタ(3レベル) — ページがJSONを返す場合、ドット/ブラケット記法で配列パスを指定。
data.items[0].titleの構造ならdata.itemsと入力してアイテム配列を作らせます。 - 関数で後処理 — 「function」列は抽出した各値に適用されます:
trim(@p)— 空白除去(@pは現在値)replace(old,new)/regex(pattern,replacement)strtoupper(@p)のような直接のPHP呼び出し- ビルトインヘルパ:
get_data()·slice()·remove()·map()
最速はセレクタを手打ちすることではなく、Loop Splitterで切った元データをAIプロンプトに流し、AIの応答をルールに自動登録させることです。次のステップ4で扱います。
数十個のセレクタを手打ちする代わりに、サンプルをAIに渡して完成したルールを受け取って適用できます。初心者に推奨の手順です。
事前条件 — ステップ3で対象URLを入力し、エディタの 「テスト」タブ から 最低1回は抽出テスト を実行して応答本文があること。この本文がプロンプトに自動で結合されます。
A. プロンプトを組み立ててコピー
- テスト結果パネルの上部で、強調表示された 🪄 「AIプロンプト」ボタン(杖アイコン)をクリック。
- 文書タイプ(HTML / JSON / XML)が自動判別され、本文が抽出されプロンプトに組み立てられます。
- ボタン直下のコードエディタパネルに、マークダウン形式のプロンプトが表示されます。内容:
- タスク説明の導入段落
- HTML/JSONのサンプル本文
- ターゲット定義 — 繰り返し区切り文字、詳細URLフィールド、ユニークキー、各カラムのラベル・変数名・タイプ・分割ルール・後処理関数
- サンプルJSONと、明示的な 「JSON以外のテキストは出力しない」 指示
- プロンプトは 多言語対応(8言語: 韓国語・英語・日本語・中国語・ロシア語・ドイツ語・フランス語・スペイン語) — 韓国語ドキュメントなら韓国語ラベル、中国語なら中国語ラベル…と自動で切り替わります。
- パネル内をクリック → Ctrl+A → Ctrl+C で全体をコピー。
B. 好きなAIに貼り付けて実行
- ChatGPT / Claude / Gemini などに貼り付けて送信。
- AIがルールのJSONを返します。
- 応答(またはJSON部分だけ)をコピー。
C. 応答を貼り付けてルールフィールドを自動補完
- 同じパネルで 📥 「パターンインポート」ボタン(インポートアイコン)をクリック — 期待フォーマットのヒント付き貼り付けテキストエリアが開きます。
- JSONを貼り付け、[パターン適用] をクリック。
- 繰り返し区切り、セレクタ、ユニークキー、詳細URLフィールドはルール上部に、各カラム(ラベル・変数名・タイプ・分割ルール・後処理関数)はフィールド一覧に一気に適用されます。変数名の衝突は自動でリネームされます。
- エディタが自動的に「fields」タブに切り替わり、すぐ確認でき、画面下に「パターン適用: N件のフィールド」のサマリトーストが表示されます。
セレクタが大まかに揃ったら、期待通りに抽出できているか確認します。入口は2つ:
- ルールカードの ⚗️ アイコン
- または、ルールエディタ上部の 「テスト」タブ
アイテムテストモーダル が次の構成で開きます:
- 上部ステータスバー — 「N件 / Mカラム」のサマリ。Nが0ならLoop Splitterが間違い — 先にそこを直します。
- エクスポートボタン — CSV · XLSX · JSON · HTML。チームにサンプルを共有するのに便利。
- 結果グリッド — Row# + 最初のアイテムから自動導出したカラムヘッダ、抽出されたアイテムが1行ずつ。
- セルhover — ホバー時に「コピー」ボタンが出て、値をクリップボードに取得できます。
結果がおかしい場合はモーダルを閉じてセレクタ/関数を調整し、再テスト — このループがパーサー作業の約70%です。
テストが綺麗に通ったら、エディタの 「保存」セクション で保存設定を確認します。
- 保存タイプ ドロップダウン — 「Database」に設定(ウィザードでデータセットを選んでいれば既に自動設定)。
- 対象テーブル / コレクション名 — 行が入る先。存在しない場合、初回実行時にエージェントが作成 し、テストで検出したカラム構成を使います。
- DBモード — データセット連携 / カスタム。カスタムではホスト · ユーザー · パスワード · データベースを直接入力(ウィザードのDBとは別のDBに書き込みたい時に便利)。
実行時の流れ
- ルールを実行すると(テストの「永続化」ボタン、または次ステップのスケジュール)、docker agentが対象URLにアクセス。
- アイテムが抽出されます: Loop Splitter → XPath/JSONセレクタ → 関数処理。
- 抽出アイテムは対象テーブルにINSERT。重複(URLハッシュまたは指定したキーで判定)は自動でスキップまたは更新されます。
- このテーブルは ステップ5のデータセットカード と同じDBに存在するので、以前作ったAPIエンドポイント
/endpoint/...から最新データがそのまま提供されます。
最後のステップでは自動実行できるようにします。ルールカードの ⏱(時計)アイコン をクリックしてスケジュールモーダルを開きます。この機能はMAX専用 — 他のプランではアイコンに「Max」リボンが表示されます。
- スケジュールフィールド:
- 開始時刻 — 時(0〜23)+ 分(0〜59)。例: 03:30 AM。
- 間隔(分) —
60= 毎時、1440= 1日1回。 - 有効化 — トグル。OFFにすると設定は保持したまま実行を停止。
- 実行モード — 単一URLモード(1つの対象URL)、バッチモード(1行1URLのリストをループ)。
- [保存] をクリック — QuickStartに記録されると同時に、選択されたdocker agentへ自動同期 されます。実際の実行はこのagentが行います。
- 以降、agentが指定間隔でルールを実行し、行をデータセットに流します。QuickStartはシグナルのみで、トラフィック経路には入らないため、帯域オーバーヘッドはありません。
マクロと連鎖(任意) — エディタの流れ図で 「マクロ選択」ドロップダウン からマクロを指定できます。スクレイプ完了直後にそのマクロが実行されます。例: 新規に取得した商品価格を昨日と比較し、N%以上下がっていたらSlackへ通知。
60〜1440 分 の間隔がポライトさと鮮度のバランスの現実解です。
データベースマイグレーション · B → A → C レプリケーション
運用中の外部DB(B)からデータを取り込み、自分のデータセット(A · Docker)に蓄積して、さらに別の外部DB(C)へ送り出す3段レプリケーションパイプラインを実際に構築します。データ一覧画面の マイグレーションボタン1つで取り込み・送り出しを切り替え、中間のAレイヤーでカラム整理・URL置換・集計までまとめて処理します。
運用DB(B)から分析DB(C)へ直送できれば簡単に見えますが、実際はカラム名が違ったり個人情報が混ざっていたりタイムゾーンが異なり、途中でひと整理する場所が必ず欲しくなります。QuickStartのデータセット(A)がまさにその役割です。
- B (外部ソース) — 実稼働中のECやERPなど原本。触ると業務が止まるので読み取り専用。
- A (自分のデータセット · Docker) — Bから引いてきたデータを受ける作業場。カラム名の置換、URL書換え、不要カラムの除外、集計カラムの追加は全てここで行う。
- C (外部ターゲット) — BIダッシュボードが繋がる分析DBや取引先DBなど目的地。Aで整ったきれいなデータだけを流し込む。
この構成の利点:
- BとCで異なるエンジン(MySQL ↔ PostgreSQL等)でもAが仲介するので問題にならない。
- Aに残るのでCを吹き飛ばしてもAから再送出できる。ロールバックが容易。
- Aで納得いくまで変換・検証でき、準備ができた時だけCへ流す。
まずはBから取り込むデータを受ける自分のデータセット(A)を作成します。
- 上部ナビのデータ → データベースへ移動。一覧画面が開く。
- 右上の[+ 新規データセット]を押して入力:
- 名前 — 例:
replication_staging - DBタイプ —
MySQLまたはPostgreSQL。Bと揃えると変換が最小になる。 - ホスト — 自分のDockerエージェントに同梱のDBがデフォルト(自動入力)。
- データベース名 — 例:
my_staging
- 名前 — 例:
- [保存]で一覧に新しい行が追加され、🔌 接続テスト · 編集 · マイグレーション · エクスポート のアイコンが並ぶ。
- まず🔌を押して「接続成功」を確認。成功してから次へ進む。
このデータセットAが、これからBから受けるデータ・Cへ送るデータが一時滞在する中間バッファになります。
hard_syncがBのスキーマをそのまま複製してAにテーブルを自動生成するためです。Bと全く異なる構造で受けたい場合は、SQLエディタで先にAのテーブルを作っておき、ステップ5でappendのみ使う方針にします。
一覧でさきほど作ったA行の マイグレーションアイコンを押します。大きな3分割モーダルが開きます。
- 左 Deck A — 先ほど作ったデータセット(
replication_staging)が自動セットされ、現行テーブル・フィールドがすぐ見える。 - 中央ツールバー — 方向表示(A → B / B → A)と[反転]ボタン、そしてアクション一覧(⚡ hard_sync, 🔄 soft_sync, ➕ append …)。
- 右 Deck B — リモートDBの接続情報を入力するフォーム。
既定の向きはA → B(自データセットを外へ送り出す)ですが、今はBから取り込むので中央の[反転]を押してB → Aに切り替えます。Deck Bのバッジが「source」、Deck Aのバッジが「target」になるのを確認。
次にDeck Bフォームに外部運用DB(B)の接続情報を入力します。
- ホスト — 例:
origin.acme.comまたは10.0.1.23 - DBタイプ —
MYSQL·POSTGRESQL·MONGODB·ELASTICSEARCHから選択 - データベース名 — 例:
sales_db - アカウント/パスワード — 読み取り専用アカウントの使用を強く推奨。
SELECTのみ可の権限なら誤操作でBを壊せない。 - [接続テスト] → 「接続成功」と共にリモートテーブル一覧が自動ロードされる。
Access denied for user 'xxx'@'1.2.3.4'の形で出る時は、そのIPをそのまま伝えれば十分です。
接続が成功するとDeck Bにテーブル一覧が現れ、右上に[次へ]ボタンが出ます。これを押すとDeck Bが「接続情報」から「テーブル選択」画面に切り替わります。
- テーブル選択 — チェックボックスで取り込みたいテーブルを選ぶ。[全テーブル]で一括選択。最初は
orders · customers · productsの3つだけに絞って小さく始める方が安全。 - 条件指定(任意) — Deck B下部のWHERE欄に
created_at > '2026-01-01'などを書くと条件一致行のみ取得。LIMITに0, 1000で1000行サンプルも可能。初回は必ずLIMITを付ける。 - フィールド確認(任意) — テーブル横の アイコンでカラム一覧を開き、コピーしたくないカラム(例:
password_hash,national_id)のチェックを外すと除外される。 - ⚡ hard_sync 実行 — 中央ツールバーの[hard_sync](雷アイコン)を押す。「{count}個のテーブルにhard_syncを実行しますか?」確認ダイアログで承認するとA側でDROP → CREATE → INSERTの順にテーブルが再構築される。進捗バーに現在テーブル/全テーブル数、および行単位進捗が表示。
- 完了すると下部ログに「Success」と出て、Deck Aのテーブル一覧が更新されて新しいテーブルが見える。
hard_sync以外の選択肢:
- 🔄 soft_sync — 主キー基準でA側の行をUPDATE/INSERT/DELETEするのみ。Aに既に蓄積された履歴は消えない。定期同期向け。
- ➕ append — Aに存在しないidのみ追加。増分取り込みに有用。
- 🔀 merge — Aのidと重複しない行のみINSERT。
Bから取り込んだ生データはAに入りましたが、多くの場合そのままCに送ると問題が起きます。Aでの整え方は2通り。
① マイグレーションモーダルの置換機能 — 中央ツールバー下部の「置換設定」で文字列を一括置換。たとえばB側の画像URLがhttps://cdn-old.acme.com/でC側ではhttps://cdn.acme.com/に変わる場合:
- [テキスト]/[正規表現]のうち[テキスト]を選択
- 左欄に
https://cdn-old.acme.com/ - 右欄に
https://cdn.acme.com/ - 次回のhard_sync / soft_sync実行時に移送中に自動で置換され、A(またはステップ6でC)に格納される。元のデータには触れない。
② SQLエディタで直接処理 — データセット一覧に戻りA行の 編集アイコンを押してSQLを直接実行。
ALTER TABLE orders DROP COLUMN password_hash;— 個人情報カラムを削除UPDATE orders SET created_kst = CONVERT_TZ(created_at, 'UTC', 'Asia/Seoul');— タイムゾーン変換CREATE TABLE orders_summary AS SELECT product_id, COUNT(*) cnt, SUM(amount) total FROM orders GROUP BY product_id;— 集計テーブル作成
変換が終わったらAの状態をプレビューしたくなります。エディタのクエリ欄にSELECT * FROM orders_summary LIMIT 20;で結果を確認してからステップ6に進みます。
Aで整えたデータを外部ターゲット(C)へ流し込みます。データセット一覧に戻りA行の を押してマイグレーションモーダルを再度開きます。
- 方向確認 — 中央ツールバーの方向表示がA → Bであることを確認。UI上のBが今回のCの位置です。ステップ3の状態が残ってB → Aと表示されている場合は[反転]でひっくり返す。
- Deck B(実際にはC)にターゲット接続を入力 — ホスト
warehouse.acme.com、DBタイプPOSTGRESQL、DB名reporting、アカウントはINSERT/UPDATE権限のある書き込みアカウントを使う。[接続テスト]で成功メッセージを確認。 - Deck Aで送出するテーブルを選択 —
orders_summary · products · customers_clean等、Aで整えたテーブルにチェック。 - アクション選択 — 状況に応じて選ぶ。
- C側が初回生成なら⚡ hard_syncで構造ごとコピー。無ければ自動生成される。
- C側に既にデータがあって定期同期なら🔄 soft_sync。A基準でCの行をUPDATE/INSERT/DELETE。
- Cには積み上げるだけなら➕ append。Aで新規追加されたidのみCに追加。
- 実行 — 確認後ボタンを押し進捗バーを見守る。ネットワークが不安定な場合は自動で行がチャンク分割されて送られるので途中で切れても再実行すれば続きから送出される。
hard_syncはCの該当テーブルをDROPして作り直すため、誤ったテーブルを選ぶと既存データが丸ごと消えます。増分同期が必要な運用環境ではhard_syncではなくsoft_syncやappendを基本にしてください。
一度手動で通したパイプラインはマクロで包めば定期実行できます。サービス → マクロで新規マクロを作成し、コード内でマイグレーション処理を呼び出します。
- マクロ内で
fetch('/dataset/api/mig_run', { method: 'POST', body: JSON.stringify({ dataset_id: 123, action: 'soft_sync', deck_b: {host, db_name, user, password}, sel_tables: ['orders'] }) })のようにマイグレーションAPIを呼ぶ構造です。(正確なパラメータはネットワークタブで手動実行時のリクエストをそのままコピーすると確実です。) - マクロのスケジュールタブでcron式を指定。例: 毎日深夜3時
0 3 * * *。 - B → AとA → Cをそれぞれ独立したマクロにしておくと片方が失敗しても他方まで止まりません。B → A成功後にA → Cを呼ぶ順序はマクロ結果の
successを見て次を呼ぶ方式で繋ぎます。
検証チェックリスト:
- Cで
SELECT COUNT(*) FROM ordersを実行しA·Bと行数が一致するか確認。 - 最近の任意のidを1つ選び、B·A·Cの3箇所で同一カラム値が取れるか比較。
- わざとBに1行追加して5〜10分後にA、次にCへ到達するか追跡。届かなければマクロ実行ログとマイグレーション結果ログを確認。
セルエディタで貼り付けDB投入 · Excel → データセット
Excel・Googleシートで整理したデータをコピー&ペーストするだけでデータセットテーブルに大量INSERTする実戦ワークフロー。一覧画面の セルエディタボタン1つで、FTPやSQLスクリプト不要、ブラウザ内で数百〜数千行を一気に積み込めます。
次のような場面では手書きSQLより貼り付け一発が圧倒的に速いです。
- マーケターがExcelで整理したクーポンコード500件をサービスDBに登録する必要がある時。
- デザイナーがGoogleシートで渡してきた商品名・価格・カテゴリの表を一括で上げたい時。
- 外部パートナーがCSVで寄越した会員リストをそのままimportしたい時。
- AIに望む出力の例100件を1テーブルに置いておきたい時。
セルエディタはExcelと全く同じ行×列のグリッドで動作し、ExcelでCtrl+Cした範囲をエディタのセルでCtrl+Vするだけでタブ区切り・カンマ区切りを自動判別し、行として流し込みます。フィールドマッピングUIなし、左上のセルから順に埋まっていきます。
上部ナビ データ → データベース を開きます。自分のデータセット一覧がカードまたはリストで表示されます。
- 投入したい自分が所有するデータセット(user_idが自分)の行を探します。公開データセットは読み取り専用で編集不可。
- 行右の セルエディタアイコン(テーブルセル)をクリック。画面を覆う大きなモーダルが開きます。
- レイアウト: 左にオプションパネル(テーブル選択・ページステップ・ソート・検索・置換)、中央にグリッド、右にツールバー(保存・追加/削除・Undo/Redo・コピー・CSV/SQLエクスポート・✨AIウィザード)。
- 左のテーブル選択ドロップダウンで投入先テーブルを選ぶと既存行がグリッドに読み込まれます。空なら空のまま。
貼り付け前にExcelの列順 = テーブルのカラム順を必ず確認。ズレると全く別のカラムに値が入ります。
- カラムヘッダ確認 — グリッド最上段(ヘッダ行)にカラム名と型が出ます。Excelの列1から順にこの並びに合わせて整理してください。
- 主キー(PK)確認 — ヘッダに🔑が付いたカラムがPK。
idがauto_incrementの時はExcelからコピーする際idカラムは空のまま残すのが基本。INSERT時にDBが自動割当します。 - NOT NULLカラム確認 — ヘッダが赤で印された列は空にできません。Excel側で必ず埋めます。
- カラムの過不足 — Excelの列がテーブルより多いと右側の超過分は無視、少ないと右側は空で入ります。
構造が合わない時は左オプションパネルのグリッド生成(X × Y)でグリッドを引き直すか、Excel側で列順をテーブルに合わせて整理してからコピーします。
ALTER TABLE ... ADD COLUMN id INT AUTO_INCREMENT PRIMARY KEY;でPKを先に作っておきましょう。
ワークフローの核心。Excel/シートでidカラムを除いた必要な範囲をドラッグ選択しCtrl+C。セルエディタに戻って:
- グリッドで投入開始の先頭セルを一度クリック。通常は左端列の、最終行のすぐ下。既存行に触れず下に追加されます。
- Ctrl+Vで貼り付け。エディタがタブ区切り(Excelコピー既定)またはカンマ区切り(CSV原文)を自動判別して行・列に展開。
- グリッドが自動拡張し、新しい行は淡い色の背景で表示されます。「まだ保存されていない新規行」の印。
- 同じ要領で複数範囲を続けて貼り付けられます。先頭セルを選び直してCtrl+Vを繰り返し。
区切り文字を明示指定したい時 — 左オプションの区切りドロップダウンでタブ · カンマ · 安全カンマ(引用符保護)を選べます。本文にカンマを含むCSVでは安全カンマを選ぶと引用符で囲まれた範囲が1セルに保たれます。
貼り付けが終わったら保存前に目視で一度確認。エディタは3つの状態を色で示します。
- 淡い背景の行 — 直前に貼った「新規行」。保存時にINSERTされます。
- セル角の黄色い点 — 既存行で値が変わったセル。保存時にUPDATEされます。
- グレーアウトされた行 — 削除予定行。下部ステータスバーに「🗑 X件 保存時に削除」と[復元]ボタンが表示されます。
よく使う編集操作:
- セルをダブルクリックで直接入力。
- 右ツールバーの / — カーソル位置に空行追加 / 現在行削除。
- Ctrl+Z · Ctrl+Y — Undo/Redo(直近50スナップショット)。
- 検索/置換 — 左オプションでテキスト/正規表現を選んでグリッド全体に一括置換。
下部ステータスに✏ X行、Yセル 編集済みカウンタが出ます。想定と違ったら保存前に直してください。
検証が済んだら保存。右ツールバーの 保存またはCtrl+S。エディタが自動で以下を処理。
- 新規行(淡い背景) →
INSERT INTO テーブル名 (col1, col2, ...) VALUES (...)を実行。auto_increment PKはDBが採番。 - 修正セルがある既存行 →
UPDATE テーブル名 SET col=val WHERE id=...を実行。変わった列のみ含める。 - 削除予定行 →
DELETE FROM テーブル名 WHERE id=...。
成功すると画面下部に「X件保存されました」トースト、新規行の淡い背景が普通色に戻り、空だったidセルにDBが採番した番号が入ります。これで既存行と区別されない正規データに。
失敗時 — メモパネルにエラー。多くはNOT NULLカラムを空にした、文字列列に数値以外が入った、unique重複などです。該当行を直して再度保存。
AIウィザードで大量作業 · 「望む値/現在値」パターン
セルエディタの「望む値・現在値」マーカーと✨ウィザードボタンを使い、翻訳・要約・分類・抽出・正規化・異常値検出など数百件のAI作業を1回のプロンプト生成で一括処理する実戦ワークフロー。例を数個示すだけでAIがパターンを学び、残り全部を同じルールで処理して返します。「繰り返しの指示文打ち込み」を実務でほぼ0にします。
最も成功する活用事例
as if to beは「すでに完成した結果(望む値)がこの姿ならば、現在のまま(現在値)も同じ論理でこう変換せよ」というパターン学習型指示方式です。変換ルールを言葉で書き出す代わりに、ルールの結果物を数個見せてAIに残りを一般化させる発想。
セルエディタはこれ用に2つのマーカー(色1・色2)を用意。
- マーカー1(望む値・基本ティール) — 結果がこうなるべきという正解例セルを印付ける。
- マーカー2(現在値・基本オレンジ) — まだ未加工のまま残る、AIが埋めるべきセルを印付ける。
この方式が強力な理由:
- 自然言語でルール説明不要。例があればAIがルールを推定。
- ルールが細かすぎて言語化しにくい作業(トーン・ニュアンス・語調の維持)にもそのまま効く。
- 1つのプロンプトで数百セルを一括処理。1件ずつAIに貼り付ける作業が消える。
- 例を足す・直すと結果の品質が即改善。チューニングループが秒単位で回る。
対象データをセルエディタに読み込んだ状態で、次の構造を先に組みます。
- 入力列 — AIが読む原文テキスト。例:
ja_text,product_desc,address_raw。 - 出力列 — AIが埋める空列。例:
en_text,summary,city。列がなければSQLエディタでALTER TABLE ... ADD COLUMN en_text TEXT;で先に追加。 - 種例行 2〜5件 — 出力列を手で直接埋めます。良い例3件で500行の品質が決まります。
良い例を選ぶコツ:
- 多様性 — 短い・長い・特殊の混合。似た例ばかりだとAIは外れ値でつまずく。
- 難易度の散らし — 簡単1、中1、厄介1。
- 望む結果の形式を明確に — 改行・大文字小文字・敬体非敬体のようなスタイルが例に現れているとAIが真似します。
右パネルのマーカーパレットで最初のスウォッチ(ティール・望む値)を一度クリックして有効化。選択中のスウォッチは縁取りが強調されます。
- ステップ2で手書きした出力列の例セル(例: 3件)をグリッドで1つずつクリックすると、そのセルがティール背景に変わります。マーキング完了の印。
- マーカーはトグル式で、同じセルを再クリックすると解除。誤マーキング時に便利。
- 複数セルをドラッグで一括選択してからスウォッチを押すと一括マーキングも可能。
ラベルを作業名に変える — スウォッチ横の鉛筆アイコンを押すとラベル(既定「望む値」)を変えられます。翻訳なら「英語翻訳」、要約なら「一行要約」、分類なら「カテゴリ」に変えておくと、ステップ5のプロンプトにそのラベルがそのまま入り、AIが作業内容をより正確に理解します。
次はマーカーパレットの2番目のスウォッチ(オレンジ・現在値)をクリックして有効化。
- 空のまま、あるいは未加工の出力列セルをグリッドでドラッグ範囲選択。例:
en_text列の4行目から最終行まで。 - オレンジのスウォッチを1回クリックすると選択セルが全部オレンジ背景に。AIが処理すべきセルの印。
- 入力列(
ja_text)はマーキング不要。AIが同じ行の入力列を自動参照します。 - このマーカーにもラベルを付けられます。例: 「英語へ」・「短く」・「カテゴリ指定」などAIに伝えたい指示を一語で。
上手くいけばグリッドにティールセル(正解例)+ オレンジセル(空のセル)が並んだ状態になります。これが「as if to be」パターンの完成形。
右ツールバーの✨ AIウィザードボタンを押します。エディタがマーカー情報を読み構造化されたプロンプトを組み立て、自動でクリップボードにコピー。画面下に「AIプロンプトがコピーされました」トースト。
コピーされたプロンプトの構造は概ね次のとおり(ラベル・例によって実内容は変わる)。
- システムメッセージ — "You are a data transformation assistant"
- タスク説明 — ラベル準拠。例: "Transform each 'Current Value' cell according to the pattern shown in 'Desired Value' examples."
- 例セル一覧 — ティールマーカー付きセルの(行,列,値)。AIはここでパターンを学習。
- 変換対象セル一覧 — オレンジマーカー付きセルの(行,列,原本入力値)。
- 出力フォーマット規定 — JSON配列
[{"pos":"行,列","return_txt":"変換値"}, ...]のみで返せと明示。
中断条件 — ティールもオレンジも1つもないと「マーカーがありません」警告で止まります。ステップ3・4に戻ってマーキングから。
コピーされたプロンプトをClaude · ChatGPT · GeminiなどのAI対話画面にCtrl+Vして送信。AIはプロンプトを解釈しJSON配列1つで応答を返します。
- AI応答からJSON部分だけをドラッグ選択してCtrl+C。前後に説明文が混ざっていてもJSON配列だけ切り出せばOK。
- セルエディタに戻り、右パネル下部のMemoテキスト領域にCtrl+V。MemoはAI結果専用の入力欄と見なしてよいです。
- 貼られたテキストが正しいJSON形式か目視でもう一度確認。形は
[{"pos":"3,5","return_txt":"Translated"},{"pos":"4,5","return_txt":"Another"}, ...]。
AIが余計な説明を付ける場合 — 「Here is the JSON you asked for:」のような文言が前に付くことがよくあります。JSON配列([で始まり]で終わる)だけを切り出してコピー。ステップ7の適用ボタンはJSONのみをパースします。
MemoにJSONを貼ったら右ツールバーの📥 結果適用ボタンを押します。エディタがJSONをパースし、各項目のpos(行,列)に対応するセルにreturn_txtを書き込みます。成功すると「Xセルに適用されました」トースト。
- 適用されたセルには修正印(黄色い点)が付きます。まだDBには反映されていません。
- 気に入らない結果があればCtrl+Zで戻せますが、AI結果全体が取り消される場合も。問題のあるセルだけ手で上書きする方が通常速いです。
- 問題なければCtrl+Sで保存。セクション1のステップ6と同じUPDATE経路。
繰り返し・バッチ戦略:
- 最初のバッチ結果を全部適用する前にサンプル10個だけ品質確認。違和感があればステップ3・4の例・ラベルを直してウィザードを再実行。
- 品質が良ければページを送って次のバッチをマーキングし、ステップ5・6・7を繰り返し。
- 全体終了後、翻訳ログ・分類ログのようなメタ列を別途設けてどのバッチでどの例を使ったかを記録しておくと、後でスタイルが変わったセクションの再実行が楽に。
プロジェクトをフォーク → カスタマイズ → 公開 · 電子メニュー(menupan)実戦
ソリューションマーケットの電子メニュー(menupan)を自分のアカウントへフォークし、ロゴを自社ロゴに差し替え、メニュー項目を実店舗のものに置き換え、配色・フォントをブランドに合わせて整え、ドメインに公開するまでを一気に進めます。0から作るのではなく既に動くプロジェクトを自分のものとして枝分かれさせ、素早く店舗用に仕立てる、最も実戦的なパターンです。
デザイン反復ループ — インスペクト→試す→AIに聞く→反映
具体的なシナリオで進めます。カフェ「ソダム」の店主は店頭タブレット用に電子メニューが欲しい。0から作るより、ソリューションマーケットのmenupan(電子メニュー)を持ってきて自店向けに着替えさせる方が圧倒的に速いです。
30〜45分で終わらせること:
- ロゴ — 既定のmenupanロゴをカフェ「ソダム」のロゴに差し替え
- メニュー項目 — デモ用(アメリカーノ4500ウォン等)を実メニューに入れ替え
- 配色・フォント — 既定のブルー基調をカフェに合うウォームベージュ+ダークブラウンに、本文フォントも可読性の高い韓国語フォントへ
- ドメイン公開 —
menu.sodam.krのような自分のドメインに公開
なぜフォークなのか
- レイアウト・DBスキーマ・管理画面が出来ているので0からの時間を90%節約。
- フォーク先は自分のアカウント・自分のドメイン・自分のDBで動作。本家ソリューションは触らず、自分のコピーだけを編集。
- 後日menupan本家に更新が来ても、自分のフォークには影響なし。
上部ナビ コミュニティ → ソリューション市場(または/solution)へ。カード形式のソリューション一覧が並びます。
- 上部のフィルタ(全体 / Project / Macro / Community / Direct)でProjectを選ぶか、検索でmenupan / 電子メニューと入力してカードを探します。
- カードをクリックすると詳細ページが開き、プレビュー・機能説明・必要な資源(ドメイン/DB)が表示されます。
- 詳細ページの 新しいプロジェクトとしてフォークボタンをクリック。フォークモーダルが開きます。
- モーダルで入力:
- ドメイン選択 — 自分の有効ドメインから。例:
menu.sodam.kr。なければ別タブで設定 → ドメインから無料サブドメイン(~.apidealder.net)を発行して戻る。 - データセット選択 — メニューデータが入るDB。新規でも既存でも可。
- プロジェクト名・説明 — 例: 名前
sodam_menu、説明「カフェソダム店頭電子メニュー」。 - 「自動デプロイ」トグル — オンならフォーク完了直後に最初のデプロイまで自動実行。初回はオン推奨。
- ドメイン選択 — 自分の有効ドメインから。例:
- [フォーク実行]クリック。30秒〜2分で完了トースト。サイドバーマイプロジェクトの上に新しい行が出来、自動でそのワークスペースが開きます。
2段構成。(a) リモート管理で新ロゴをサーバへアップロード、(b) プログラムエディタで既存ロゴURLを新URLへ。
(a) リモート管理に新ロゴをアップロード
- 上部ナビ サービス → リモート管理へ。左のサーバ一覧でフォークしたプロジェクトのドメイン(
menu.sodam.kr)をクリック。緑点が点いているのが正常。 - 中央領域でパスを
/public/assetsへ移動(パス入力欄に直接タイピングしてEnterが最速)。 - 下部アクションバーの[ファイルアップロード]でカフェロゴ(
sodam_logo.png)を上げます。単一ファイルなら圧縮版ではなく通常のアップロードを。 - アップロード後、ブラウザで
https://menu.sodam.kr/assets/sodam_logo.pngを直接開いて200 OKで表示されることを確認。
(b) プログラムエディタでロゴURL置換
- ワークスペースに戻り、プロジェクトの プログラムを押す。メニュー画面を構成するプログラム一覧(通常
main·menu_list等)。 - ロゴが出るプログラム(通常
main)をダブルクリックでエディタを開く。 - 右上の検索/置換(Ctrl+H)で既存ロゴURLを検索。だいたい
/assets/menupan_logo.png等。 - 検索欄に
menupan_logo.png、置換欄にsodam_logo.pngを入れてすべて置換。HTML・CSS両方で一括置換されます。 - エディタを保存(Ctrl+S)後、右パネルのプレビューで自分のロゴが出ることを確認。
/assets/sodam_logo.pngを使ってください。相対パス(../assets/...)はルーティング次第で壊れます。
menupanは店舗スタッフがメニューを追加・編集・削除できる管理画面を同梱しています。2方式あり管理画面の使用を強く推奨。
(推奨)管理画面の利用
- 公開ドメインの
https://menu.sodam.kr/admin(またはmenupanが定めた管理パス)にアクセスしてログイン。フォーク直後の既定管理者情報はソリューション詳細ページのREADMEに記載。 - 左メニューでメニュー管理をクリック。カテゴリ(コーヒー・デザート・ノンコーヒー)・項目(アメリカーノ・ラテ等)が表/カードで表示。
- サンプル項目をすべて削除後、自店の実メニューを1行ずつ追加:
- 名前(
アメリカーノ)・価格(4500)・説明(...)・カテゴリ(コーヒー)・写真(リモート管理にアップした写真URL)
- 名前(
- 編集・並び替え・表示/非表示の切替などの日常運用はすべてここで完結。店舗スタッフでも使える画面はこちら。
(代替)DBで直接修正
- 管理画面が触れない精密操作(例: コーヒー全品500ウォン値上げ一括)ならデータ → データベース → フォーク時のデータセット → セルエディタを開く。
menu_itemテーブルを直接編集、またはSQLエディタでUPDATE menu_item SET price = price + 500 WHERE category='コーヒー';。(セルエディタの使い方は実戦演習 → セルエディタで貼り付けDB投入参照)- 注意: 管理画面が知らないカラムを触ったり、PK・FK制約を壊すと管理画面が動かなくなることが。だから日常編集は管理画面推奨。
/assets/menu/*.jpgのような一貫パスで管理した方が後のバックアップ・移転に有利。
コードを直す前にブラウザで直接値をいじって気に入る色を見つける段階。変更は一時的で更新すれば消えるので安心して試せます。
- 公開メニュー(
https://menu.sodam.kr)をChromeで開きF12で開発者ツールを起動。または右クリック → 検証(Inspect)。 - 開発者ツール左上の矢印+四角アイコン(要素選択)を押し、画面上で色を変えたい領域(ヘッダ、メニューカード背景等)をクリック。右のStylesパネルにそのCSSルールが並びます。
- 色値(
background-color: #2563eb;等)にマウスを乗せると小さい色ボックス。クリックでカラーピッカーが開き、ドラッグかhex直入力で色を変えられます。 - フォントも同じ要領で
font-family: ...;をクリックして別の名('Pretendard', 'Noto Sans KR', sans-serif)に変更。 - 気に入る組み合わせが出たらそのhex値とフォント名をメモ。次のステップでAIに見せたり、ステップ7でコードに反映する時に使います。
便利な小技:
- 複数要素の同時比較 — ヘッダ色を変えたら本文と合わなくなった、を二色を見比べて調整。
- Computedタブ — 実際の最終値(継承込み)を表示。値の出処追跡に便利。
- :hover強制 — Stylesパネル上の
:hovで:hover·:focus状態を強制トグル、ホバー時の色も事前検証可能。
ステップ5で手で選んだ色がしっくり来ない、「このカフェに合うトーンは何が他にあるか」を知りたい時、AIにトーン推薦を依頼すると候補が即5〜10個出ます。Claude/ChatGPTにこんなプロンプト:
カフェ「ソダム」の店頭電子メニューを作っています。
コンセプトは「温かく落ち着いた韓国式カフェ」、
空間はウッドトーン内装+黄色照明。
現在の配色は:
- ヘッダ背景: #2563eb (ブルー)
- 本文背景: #ffffff
- 文字: #1f2937
- 強調: #2563eb
このコンセプトに合う配色5セットを推薦してください。
各セットはヘッダ・本文背景・本文文字・強調の4色を
hex値で、短い一行説明も付けて。
韓国語の可読性が良く、この雰囲気に合うGoogle Fonts
または無料韓国語フォントも3つ推薦してください。AIはおおよそ次のような形で返します。
- セット1(温かいベージュ・ダークブラウン) — ヘッダ
#6b4423、本文背景#f5ecd9、文字#3c2415、強調#c97a4a· ウッドトーン+黄色照明に自然になじむ - セット2(モダンミニマル) — …
- …
もらった候補の検証順:
- ステップ5のF12インスペクトに戻り、もらったhex値を一つずつ実際に当てて気に入るセットを選ぶ。
- 比較しているうちに「ヘッダはセット1、強調はセット3」のような組み合わせもよくあります。それもメモ。
- フォントは
https://fonts.google.comで検索し、実際の字形が自店メニューに合うか確認。
F12とAIで決めた色・フォントを実コードに書きます。これで更新しても残り、他人が見ても同じ見た目になります。
- ワークスペース → プロジェクト → プログラムでデザイン関連プログラム(通常
mainまたはtheme)をダブルクリックしてエディタを開く。 - 右上のSCSS(またはCSS)タブへ。色変数定義は通常ファイル先頭にまとまっています(
$primary-color、$bg-color等)。 - F12で確定したhex値をその変数へ:
$header-bg: #6b4423;$body-bg: #f5ecd9;$text-main: #3c2415;$accent: #c97a4a; - 韓国語フォントはSCSS最上部に
@import url('https://fonts.googleapis.com/css2?family=Pretendard&display=swap');を1行追加し、bodyのfont-familyを'Pretendard', sans-serifに。 - Ctrl+Sで保存。下部プレビューに即反映を確認。
公開する2つの方法
- 方法A — 手動デプロイ(既定): ワークスペース上部の🚀 デプロイボタンをクリック。1〜2分のビルド・転送が走り、完了で
menu.sodam.krに新デザインが反映。最初はこの方法が安全。 - 方法B — 保存時自動デプロイ(推奨: 高速反復): ワークスペース上部の「保存時自動デプロイ」トグルをオンにするとCtrl+Sのたびに自動でデプロイまで実行。色・フォント・メニューを素早く変えながら本番で即確認するのに最適。営業中はオフを推奨(編集中のチラつき防止)。
デプロイ完了後、https://menu.sodam.krをスマホ・タブレットで開いて最終確認。店頭タブレットに映せばお客様が見る画面のできあがり。
ブロックビルダー × プログラムビルダー × データバインディング · JSON構造で動くフロント作り
ブロックビルダーでデザインされた部品(ブロック)を作り、プログラムビルダー(コーダービルダー)のリストステップのスロットに差し込んでから、データセットの実データ行をスロットの変数にバインドする作業です。このパターンが手に馴染むと、JSON構造1枚がそのままフロントページになる画面を自分で作れるようになります。本ガイドは初めて触れる方向けに「商品リストページ」1画面に絞った簡略版です。
構造を一目で — ブロックライブラリ · フレームのスロット · データセット
フレームは写真を入れる額縁、スロットは額縁内で写真を受ける溝、ブロックはデザイン済みの1枚の写真、データセットは写真の上に印刷される文字を供給するアルバム、と捉えるとすっと入ってきます。額縁に写真を入れ、写真の空き場所にアルバムの行を一行ずつ流し込む——それが今日の作業のすべてです。
データが流れる経路 — 4段パイプライン
ゼロからfetch()を書いてv-forを組むのではなく、すでに作られたデザイン部品(ブロック)をフレームのスロットに差し込み、データセットを軽く繋ぐだけでページが完成するパターンがあります。本ガイドはその一周を端から端まで通すのが目的。
もう一度比喩で: 空の額縁(フレーム)にデザイン済みの写真(ブロック)を入れ、写真に印刷する文字を供給するアルバム(データセット)を繋ぐ。最後に額を壁に掛けるのがデプロイ。
今日作る画面 — 「うちの店の商品リスト」。上にヘッダー、中央に商品カード10個(データセットの実データ行)、下にフッターという普通の1画面。
- もう一歩進めば: 相場・ニュース・ランキングのように8〜10個のデータセットテーブルを list / list3 ... list10 といった複数変数に同時にバインドし、ページ全体をJSON構造で描き出す大きな事例もあります。本ガイドはその第1針、変数1つ(list) + データセット1つ(products)に絞りました。
- なぜこの方式が良いか — デザイナーはブロックビルダーで外観だけ、データ担当はデータセットだけ、ページ担当はプログラムビルダーでスロットマッチングだけを見ます。役割が綺麗に分離し、データが変わってもデザインはそのまま、デザインが変わってもデータはそのまま動く。
まずスロットに流す実データをデータセットに用意。画面ができてもデータが空だと「ちゃんと動いているか」が分からない。データ先、画面後が定石。
- 上部ナビ データ → データベース。自分所有のデータセットがなければ[+ 新規データセット]で作成。例: 名前
shop、MySQL/PostgreSQL。 - そのデータセットの SQLエディタで
productsテーブル作成:CREATE TABLE products (id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100), price INT, image_url TEXT); - 同じデータセットの セルエディタで
productsを開き5〜10行入力。Excelで整理した表をCtrl+Vで貼ると一瞬で入ります(詳細は実戦 → セルエディタで貼り付けDB投入)。 - SQLで一行確認:
SELECT * FROM products LIMIT 3;。ステップ6でこのデータセットをlist変数に繋ぎます。
必ず入れる列 — ブロックデザインで使う列だけで十分。name · price · image_urlでOK。多い分には無害ですが、最初は単純な方がデバッグが速い。
次にスロットに差し込むブロックをデザイン。上部ナビ デザイン → ブロック(または/layout/block)でブロックライブラリ。右上[+ 新規ブロック]。
- 名前 —
product_card_listのように分かりやすい名前。 - HTML欄にカードリストのマークアップ。要点は変数名を
listに:<div class="card-grid">
<div class="card" v-for="item in list" :key="item.id">
<img :src="item.image_url">
<div class="name">@{{ item.name }}</div>
<div class="price">@{{ item.price }}円</div>
</div>
</div> - CSS/SCSS欄にカードグリッドのスタイル:
.card-grid { display:grid; grid-template-columns:repeat(3,1fr); gap:16px; }.card { padding:14px; border:1px solid #eee; border-radius:8px; } - sample_data — プレビュー用ダミーデータをJSONで。キーは
list:{ "list": [
{"id":1,"name":"サンプルA","price":1000,"image_url":"/assets/sample.jpg"},
{"id":2,"name":"サンプルB","price":2000,"image_url":"/assets/sample.jpg"}
] } - 保存。ブロックビルダーのプレビューパネルにsample_dataから2カードが自動表示されます。このプレビューがちゃんと出るかが核心の検証。出ない場合はHTMLの
list変数名とsample_dataのlistキーが一致するかから確認。
次はページ(プログラム)作り。サービス → プロジェクト → [マイプロジェクト] → + 新規プログラムまたは既存プログラムのプログラムビルダー(コーダービルダー)を開く。両者は同じ画面の別名で、8つのステップタブで構成。
- 8タブ — db · list · detail · search · hook · style · code · menu。2番目のlist(リスト)へ。
- レイアウトモード切替 — listタブの上に「フィールド / スロット」2モード。既定は「フィールド」(table-like)。今回はデザイン済みブロックを差すので「スロット」に変更。画面がスロット構成用の3段UIに切り替わる。
- 1) フレーム選択 — スロットがいくつ・どう並ぶ額縁(フレーム)を使うか。
- 2) スロット構成 — 各スロットにどのブロックを差すか、データ変数をどう対応付けるか。
- 3) コードプレビュー — システムが合成した結果コードの確認。
- 「フレーム / スロット」の語が分かりにくければ「3段の額に写真3枚を入れに来た」と思えばOK。次のステップ5でフレームを選びます。
スロットモード画面の1) フレーム選択でドロップダウンを開いて適当なフレームを選ぶ。通常は「3-row(上/中/下)」のような単純なもので十分。フレームを選び[適用]を押すと2) スロット構成に自動でスロット行が作成される(スロット1、スロット2、スロット3 …)。
- スロット2(中央)のブロック選択ドロップダウンを開き、ステップ3で作ったproduct_card_listを選択。オプション表示は通常
id - 名前 - 作成者の形。 - 選択した瞬間、そのスロット領域にブロックのsample_dataプレビューが入ります。カード2枚(サンプル)がスロットに見えればOK。
- スロット1(上)・スロット3(下)には予め用意したヘッダー/フッターブロックを同様に差すか、空のままでも可。最初はスロット2だけで十分。
- 各スロット行の横にdata_placer (ソースセレクタ)とdata_selector (ターゲットセレクタ)欄があるが、今は両方とも
listのままで。意味はステップ6で詳しく。 - ここまででスロットにブロックは入ったが、まだサンプルデータで動作中。データセット接続は次のステップへ。
本ガイドで最も重要なステップ。ブロック内のlistという変数が実際のproductsテーブルのデータで満たされるように接続。
2つの変数の正体:
- data_placer (ソースセレクタ) — ブロック内で書かれた変数名そのまま。我々のブロックは
v-for="item in list"なのでlist。 - data_selector (ターゲットセレクタ) — ページ全体でそのデータを呼ぶ名前。1ページにカードリストが2つあれば
listは衝突するのでproduct_list·review_listのように別名にマッピング。1つだけならlistのままでOK。
今回は単純化のため両方listのまま進めます。
実データ接続 — プログラムビルダー上部(または別パネル)の「データ変数 / data_vars」セクションを開く。空なら+ 追加で1行作成。
- 変数名:
list(ステップ5のdata_selectorと一致)。 - データセット: ドロップダウンでステップ2で作った
shopを選択。 - テーブル:
products。 - WHERE(任意): 空なら全件。例:
price > 0。 - LIMIT(任意):
0, 20で先頭20行。 - ORDER BY(任意):
id descで新しい順。 - 保存。
これで内部的にはJSON構造1枚が出来上がります(直接見えませんが概念上):
{"var_name":"list","dataset":{"id":42,"table_name":"products","str_limit":"0, 20","str_order":"id desc"}}
このJSONがページバックエンドレンダラーがデータ取得する仕様になり、実行時にSELECT * FROM products ORDER BY id desc LIMIT 20の結果をlist変数に入れて、ブロックのv-forが流れます。
recommend_list·new_listとして、data_varsで両方ともproductsテーブルの異なるWHERE条件で繋げます。
すべての設定が終わったらプログラムビルダーの3) コードプレビュー(またはcodeステップタブ)へ移動し、システムが合成した結果コードを確認。
- コード生成(同期)ボタンを押すと、システムが以下を自動合成:
- フレームのHTML骨組み +
<[slot-1]>·<[slot-2]>·… 位置に各スロットブロックのHTMLを差し込み。 - ブロック内の
list→ ステップ5で決めたdata_selectorに自動置換(今回はそのままlist)。 - data_varsの変数定義がページ初期化コードに追加。
- フレームのHTML骨組み +
- 生成コードを確認。
v-for="item in list"がそのまま生きていて、ページ上部にlist = await fetch('/api/...')または server-side で注入されるコードが見えれば正常。 - Ctrl+Sまたは保存。プレビューパネルに実際のproductsテーブルのデータがカードとして流れているか確認。サンプルの2枚ではなくデータセットの5〜10行が出れば正常。
- 最後にワークスペースの🚀 デプロイ(または「保存時自動デプロイ」)で本番確認。
JSON構造がそのままフロントである理由 — この時点でページの全動作は次の3つのJSONに集約されます。
- slot_info — どのフレーム + どのスロットにどのブロックを入れたか。
- data_vars — 各変数がどのデータセット·テーブル·条件に繋がるか。
- ui_info — 追加UIオプション(今回はほぼ空)。
コードを手書きしなくてもこの3つのJSONを整えるだけでページが再描画されるので、以後はデータセットを差し替えるだけ、ブロックを変えるだけで同じページを素早く変形できます。最初は1画面ですが、このパターンが手に馴染めば10画面作る時間が1画面に近づく魔法が起こります。
listか)、③ productsテーブルに行があるか、④ WHERE条件が厳しすぎて0行になっていないか。ほぼすべての場合この4つのどれかで詰まります。
パーサ応用 · cURLをそのまま持ち込んでデータセットでループ呼び出し
プレーンな GET ?q=... では足りないサイト —— クッキー・CSRFトークン・Authorizationヘッダー・POST JSONボディがすべて必要なサイトのレスポンスを正確に再現し、データセットの行ごとに変数を差し替えて N回繰り返し呼び出し、結果を新しいデータセットに溜める流れを最初から最後まで体験する練習です。
一望できるパイプライン —— ブラウザ要求 → cURL複製 → 変数注入 → ループ呼び出し
要求をキャプチャ (F12)
パケットを丸ごと複製
1回そのまま検証
${変数}でマーク
+ データセットでループ
cURLを一行ずつ分解 —— URL · クッキー · ヘッダー · ボディ
ブラウザの一回のリクエストには通常、URL/メソッド、セッションクッキー、認証/AJAXヘッダー、POSTボディの4要素が一塊になっています。行ごとに変わる箇所だけを ${変数} に置き換え、残りはキャプチャしたままで構いません。
${名前} を書きます。
ループの全体像 —— データセット行 → 変数置換 → レスポンス収集
左のデータセットの一行が中央のcURLテンプレートの ${変数} 位置に順に注入され、その結果が右のデータセットに一行ずつ追加されます。100行あれば呼び出しも自動で100回 —— 人が押す必要はありません。
注入
蓄積
シンプルなサイトなら https://site.com/search?q=hello のような GETのURL一行で終わります。しかし実務で出会うサイトの半分以上はそう単純ではありません。
- ログイン後にしか見えない検索結果 —— セッションクッキーがないと空ページかログイン画面が返ります。
- POST + JSONボディ —— 検索語がURLになく、リクエストボディの中にあります。
{"q":"hello","page":1,"size":20}のように。 - CSRF / Bearerトークン —— 毎リクエストごとに別ヘッダーで一緒に送らないと結果が返りません。
- X-Requested-With · Referer · User-Agent —— AJAX識別ヘッダーが抜けるとサーバが意図的に空のレスポンスを返すことがあります。
これらを手で1つずつ書き写すのは非現実的です。最短路は ブラウザが実際に送ったリクエストを一行のcURLコマンドとしてまるごとコピーし、行ごとに変わる部分だけ変数に切り出して残りはそのままにすることです。
今日の成果物 —— キーワードがN個入ったデータセット(例:keyword_list)を用意し、サイトの検索APIをN回呼び出してレスポンスを別のデータセット(例:search_results)に積み上げるところまでが目標です。
Chrome(またはEdge)で対象サイトを開き、いつも通り検索を1回実行します。
- F12でDevToolsを開き、上部の Network タブへ移動。
- 検索を実行するとリクエストがどっと並びます。欲しいのは大抵、名前に
search、list、query、apiが含まれ、レスポンスがJSONの行です。 - その行をクリックし、右側の Response タブで本文が欲しいデータかどうかを確認。
- 合っていればその行を 右クリック → Copy → Copy as cURL (bash)。WindowsでもbashフォーマットがクォートのCompatibilityが最も良好です。
クリップボードに curl 'https://...' -H 'Cookie: ...' -H 'Authorization: ...' --data-raw '{...}' のような一行コマンドが入りました。長く見えますが URL · クッキー · 全ヘッダー · ボディ が全て含まれています。
cURLをいきなりパーサに貼ってはいけません。まずはPostman(またはInsomnia、Bruno)で 同じものを1回送って成功するかを必ず確認します。ここで詰まればパーサ規則も詰まります。
- Postmanを起動 → 左上の Import → Raw text タブ。
- クリップボードのcURLをそのまま Ctrl+V で貼り、Continue → Import。
- 全ヘッダーとボディが自動で入った新しいリクエストタブが開きます。右上の Send をクリック。
- レスポンスが200で、本文がブラウザで見たものと同じなら成功。401/403/302や空本文が出たら以下を点検します。
- クッキー期限切れ —— 最も多い原因。ブラウザに戻ってログイン状態を再確認し、F12で再度Copy as cURL。
- ヘッダー欠落 —— Postmanの自動変換が1〜2個のヘッダーを落とすことがあります。ブラウザのHeaders欄とPostmanのHeadersタブを並べて1行ずつ比較。
- Referer / Origin —— 一部サイトはこの2つがないと空が返ります。ブラウザが送っていれば同じものを追加。
動くPostmanリクエストを見ながら、次の呼び出しで変わる部分を印付けします。よくある候補:
- POSTボディ内の検索語 ——
"q":"hello"→"q":"${query}" - ページ / オフセット ——
"page":1→"page":${page}(数値はクォートなし) - カテゴリ / フィルタ ——
"cat":"food"→"cat":"${category}" - 日付範囲 ——
"from":"2026-04-01"→"from":"${date_from}" - URLのパス変数 ——
/api/user/12345→/api/user/${user_id}
コツは これから作るデータセットの列名と完全に同じ名前で変数を作ることです。列名を query · page · category にするなら、cURL内も ${query} · ${page} · ${category} で統一します。同名なら次のステップでマッピング不要で自動接続されます。
記法 —— パーサは ${名前} パターンを認識します。スペース、日本語、特殊記号は使わず、英数字とアンダースコアのみで命名してください。
パーサはデータセットの行を1つずつ読んでcURLの変数位置に注入します。なのでこのステップでは、呼び出したいN個の入力組合せをデータセットとして事前に作ります。
- 左メニュー データ > データセット → 右上 + 新規データセット。
- 名前は
keyword_listなど分かりやすいもので。ステップ4でマークした変数名と完全に同じ名前の列を追加 —— 例:query (varchar) · page (int) · category (varchar)。 - 行追加は2通り —— (a) UIから1行ずつ手入力、(b) Excel/SheetsでまとめてからCell Editorに 貼り付け → DB投入(セル貼り付けガイド参照)。
- 最初は欲張らず 3〜5行 だけ入れて次へ。100行から始めると、1回のミスで100回の誤った呼び出しが飛びます。
レスポンス保存用データセットも併せて先に作ると良いです。例: search_results テーブルに query, rank, title, url, snippet 列。ステップ6でレスポンスをどこへ書き込むか指す時に使います。
${変数} が1文字でも違えば自動接続が切れて手動マッピングが必要になります。ステップ4で決めた変数名を コピーして 列名にそのまま貼り付ける習慣が安全です。
いよいよパーサで新規規則を作りながら、用意したcURLとデータセットを接続します。
- 左メニュー データ > パーサ → 右上 + 新規規則。
- テストページ(基本URL)入力欄 —— cURLの先頭部分にあるエンドポイントをそのまま記入。例:
https://example.com/api/search。URLに変数が入る場合は${user_id}のように同じ表記で書きます。 - cURL入力欄 —— ステップ4で変数マーキングまで終えたcURL一行を丸ごと Ctrl+V。パーサがメソッド/ヘッダー/クッキー/ボディを自動分離認識し、
${...}パターンを発見して変数候補に登録します。 - 入力データセット選択 —— ステップ5で作った
keyword_listを選択。変数名が一致すれば自動マッピング、違えば隣にマッピング用ドロップダウンが出ます。 - レスポンス書き込みデータセット選択 ——
search_resultsを選択。レスポンスJSONのどのパス(例:data.items[*])を1行として展開するかをJSONパス入力欄で指定します。 - 保存すれば規則が1件登録されます。まだ実行前です。
2つの実行モードがあります。
- ① 直接入力1回テスト —— 規則ページの ▶ 実行 ボタン横の 変数入力 で
query="渋谷 ラーメン", page=1を直接入れて1回だけ呼び出し。レスポンス本文プレビューと抽出された結果行が同じ画面に表示されます。レスポンス形式の確認が終わるまでこのモードを繰り返します。 - ② データセットでループ実行 —— 変数入力パネルを 「データセットから取得」 に切り替え → ステップ5の
keyword_listを選択 → 実行。プログレスバーが0/N → N/Nへ伸び、レスポンスが1行ずつsearch_resultsに蓄積されます。
実行中に注視すべきもの —— エラー行数(空レスポンス、401、5xx)、レスポンス本文サンプル、蓄積行数。1〜2行の失敗は普通ですが、50%以上失敗するなら直ちに中断してcURLを点検してください。
スケジュール実行 —— 規則詳細の スケジュール タブで毎日/毎時/任意の時刻に自動実行を仕掛けられます。キーワードリストを置いておけば毎日新しい結果が積み上がる単純なワークフローが完成します。
リモート管理 · 基本
デザイナーから受け取った画像・ロゴ・フォント・CSSなどのデザインアセット一式をデプロイ済みサーバーにアップロードし、シングルファイルプロジェクトからそのパスを参照して実際に画面に描画されるところまでを通しで確認する手順です。FTPソフトは不要で、ブラウザの中ですべて完結します。
アップロードの前に、デザイナーから受け取ったファイルを1つのzipアーカイブにまとめます。まとめ方でサーバー上のパスが変わるので、次のルールを守ってください。
- 必ずトップフォルダ1つで包む — 例:
design_assets/フォルダの中に画像とcssを入れ、そのフォルダ自体をzip化します。展開後は/アップロード先/design_assets/logo.pngのようにフォルダ名が1階層残ります。 - ファイル名・フォルダ名は半角英数・ハイフン(-)・アンダースコア(_)のみ — 日本語や空白が混ざるとURL参照が壊れやすくなります。例:
メイン バナー.png❌ →main-banner.png✅ - 対応形式 — .zip · .tar · .tar.gz · .tgz。ほとんどの場合.zipで十分です。Windowsはフォルダ右クリック→「ZIP形式に圧縮」、macOSはFinderで右クリック→「"~"を圧縮」。
- レイアウト例 —
design_assets/
├─ images/logo.png
├─ images/hero.jpg
├─ fonts/pretendard.woff2
└─ css/theme.css
images/logo.pngのように直接参照したい場合は、外側のフォルダを作らずにimages・fonts・cssなどのサブフォルダだけをzipに入れます。どちらかの方式を選んだら、プロジェクトを通して一貫して使い分けましょう。
上部ナビまたはダッシュボードからサービス → リモート管理に移動します。左にサーバー一覧サイドバー、中央に4カラムのファイルエクスプローラー、下部にアクションバーが表示されます。
- 左側のサーバー一覧でアップロード先のドメイン(例:
myshop.apidealder.net)をクリックします。ドメイン名の先頭の小さな丸が現在の状態を示します。- 緑の点 — 正常。クリックでファイル一覧がすぐに開きます。
- 灰色の点 — オフライン。コンテナが停止中か、まだデプロイされていません。
- 白い点 — 状態確認中。
- 一覧が空の場合は「先にサーバーをデプロイしてください」の案内が出ます。その場合はシングルファイルやプロジェクトを一度デプロイしてから戻ってきます。
- サーバーを選ぶと中央にルート(
/)フォルダが展開され、実際のファイル構造が見えます。
アセットはブラウザからURLで読み込むので、必ずWebから到達できる「公開フォルダ」に置く必要があります。シングルファイルベースのサーバーでは一般的にpublic/assetsを使うのが無難です。
- パスバー — 中央上部の家アイコンで最上位へ一発で戻れ、スラッシュで区切られた各区間をクリックすればその位置へジャンプします。
- パス直接入力 — その横の入力欄に
/public/assetsをタイプしてEnterを押せば、途中のフォルダを1つずつ入ることなく一度に移動できます。 - assetsフォルダが無い場合 — 下部アクションバーの[新規フォルダ]ボタンで
assetsを作ってから入ります。名前には半角英数・ドット(.)・ハイフン(-)・アンダースコア(_)のみ使えます。 - 移動後はパスバーが
/public/assetsになっているか必ず確認してください。このフォルダがアーカイブの展開先になるので、場所を間違えると削除して再アップロードする手間が発生します。
/)やシステムフォルダ(/etc, /var/log)はHTTPで公開されません。アップロード前に必ず「ここに置いたときhttps://ドメイン/assets/ファイル名でブラウザから届くか?」を頭の中で一度描いてみる癖をつけましょう。
パスを/public/assets(またはお好みの公開フォルダ)にした状態で、下部アクションバーの[圧縮アップロード]ボタン(クラウド+上矢印のアイコン)を押します。アップロードモーダルが開き、3段階で進みます。
- ドロップゾーン — 点線の枠にzipファイルをドラッグ&ドロップするか、枠をクリックしてファイル選択ダイアログを開きます。.zip · .tar · .tar.gz · .tgzに対応しています。
- プレビュー — モーダルにzip内のフォルダ/ファイルツリーが描画され、上部にファイル名、サイズ、展開先(
/public/assets)が表示されます。ここで外側のラッパーが意図通りか、想定外の隠しファイル(macOSの.DS_Storeなど)が混ざっていないかを目視確認します。違う場合は右上の[x]でファイルを差し替えられます。 - 送信 — [送信]を押すとファイルが1MBずつ分割されて送信され、進捗バーがリアルタイム表示されます。通信が不安定でもつながり直せ、数百MBの大容量ファイルも安定してアップロードできます。
- 送信完了後、サーバー側で自動で解凍され、現在のフォルダがリフレッシュされて今アップロードした
design_assetsフォルダ(またはimages/fonts/cssフォルダ)が表示されます。完了トーストも出ます。
圧縮ではなくファイル数個をそのままアップしたい場合は、隣の[ファイルアップロード]ボタンで複数選択すれば解凍なしで現在のフォルダにそのままコピーされます。
アップロードしたファイルはデプロイ済みドメインのURLから直接アクセス可能です。例えばmyshop.apidealder.netサーバーの/public/assets/design_assets/images/logo.pngにアップロードした場合、ブラウザではhttps://myshop.apidealder.net/assets/design_assets/images/logo.pngで開けます。(publicはWebルートなのでURLからは省かれます。)
続いてシングルファイルエディタ(サービス → シングルファイル)を開き、アップロードしたアセットを参照します。
- HTMLタブで画像を挿入 —
<img src="/assets/design_assets/images/logo.png" alt="logo"><img src="/assets/design_assets/images/hero.jpg"> - SCSSタブで背景・フォントを参照 —
.hero { background: url("/assets/design_assets/images/hero.jpg") center/cover; }@font-face { font-family: 'Pretendard'; src: url("/assets/design_assets/fonts/pretendard.woff2") format('woff2'); } - 重要なルール — パスは必ずスラッシュ(/)から始まる絶対パスを使います。相対パス(
../assets/...)はプレビューと本番で挙動が変わることがあるので避けましょう。 - 外部CSSをまるごと読み込みたい場合はSCSSタブの先頭に
@import url("/assets/design_assets/css/theme.css");を追加します。
参照を書いたら、シングルファイルエディタ右上の[Run ▶]でまずプレビューを確認します。問題がなければ[Deploy 📦]を押して本番ドメインに反映します。
- Runプレビュー — エディタ右側のパネルにリアルタイムで結果が描画されます。画像が正しく表示されるか、フォントが当たっているか、CSSが崩れていないかを確認します。
- Deploy — デプロイボタンを押すと進行状況がステップ表示され、通常1~2分で完了します。完了後、結果ボックスにドメインのリンクが表示されます。
- 本番ドメインで確認 — リンクを新しいタブで開く、または直接
https://ドメイン/にアクセスします。ハードリロード(Ctrl+F5またはCmd+Shift+R)でキャッシュを消して見るのがおすすめです。 - 画像が表示されない場合はリモート管理に戻ってパスを再確認。フォルダ構造が期待と違うときは、そのフォルダを削除してステップ4からアップし直すほうが早いです。
logo.png → logo_v2.pngのように名前を変えて参照も併せて更新しましょう。
リモート管理 · 上級
デプロイ済みサーバーでプログラムが期待通りに動かないときに、storage/logsに溜まるログファイルを、ターミナルパネル内のgrep・cat・tailなどのCLIコマンドで調べて原因を突き止める実戦デバッグ手順です。ブラウザ内で開くターミナル1つだけで、SSHクライアント無しにサーバー内部を直接覗き込みます。
表面の症状は似ていても原因は様々です。次のどれかに当てはまるならサーバー側のログを読むのが最短ルートです。
- 500 / 502 / 504などのサーバーエラー — ブラウザには「エラーが発生しました」程度しか出ず、本当の原因はサーバーログだけに残ります。
- 真っ白な画面 — PHPの致命的エラーで出力が止まっているケースが多いです。Fatal ErrorやParse Errorがログに刻まれている可能性大。
- APIが400/422で落ちるが原因が曖昧 — どのバリデーションルールに引っかかったかはコントローラーのログにあります。
- バックグラウンド処理(キュー・スケジュール・マクロ)が「動いているようで結果が無い」 — 静かに失敗しているとログにだけ痕跡が残ります。
チェックする主なログファイル:
storage/logs/laravel.log— PHP/Laravel全体のログ。最もよく見る。storage/logs/laravel-YYYY-MM-DD.log— 日次ローテーションが有効なとき。storage/logs/worker.log・マクロ実行ログなど、機能別にファイルが分かれることも。
ブラウザでサービス → リモート管理に移動します。
- 左のサーバー一覧で問題のあるドメインをクリック。緑の点なら接続可能です。灰色/白なら1~2分待ってからもう一度。
- 中央エリア上部ツールバーのターミナルアイコン(▷_)をクリック。画面下部からターミナルパネルがせり上がってきます。同じアイコンをもう一度押すと畳まれます。
- パネル上部に現在の作業フォルダ(例:
/var/www/html)が表示され、入力欄でカーソルが点滅します。このカーソルは選択したサーバーのシェルに直結しているので、打ったコマンドはそのサーバー上で実行されます。 - まず現在地を確認します。
pwdls
通常はLaravelプロジェクトのルート(/var/www/html)から始まります。
/bin/shでありbashではありません。bash専用の構文([[ ... ]]や配列など)は動かないことがあります。cd · ls · cat · grep · tail · headのような基本コマンドは問題ありません。
Laravelプロジェクトのログはstorage/logsフォルダに溜まります。ターミナルでそこへ移動します。
cd storage/logs— 現在位置基準での移動。すでに/var/www/htmlにいるならこれで十分。cd /var/www/html/storage/logs— 絶対パス指定。どこにいても確実に到達できます。pwd— 現在地確認。移動後にチェックして/var/www/html/storage/logsになっているか見ましょう。
現在の作業フォルダはターミナルが記憶するので、一度cdで入ればその後のコマンドはすべてこのフォルダ基準で実行されます。
別の方法:先にファイルエクスプローラーで/storage/logsまで移動しておき、その状態でターミナルを開くとパスが自動で追従します。パス入力が面倒なときに便利です。
cd ..)lsでフォルダ構造を見回して実際のログの場所(log/、logs/、/var/log/nginx/など)を先に探しましょう。
フォルダに入ったら、まずどのファイルがあるか、どれが最近更新されたかを見てから、該当ファイルの中身を開きます。
ls -lhrt— 更新時刻の昇順で一覧表示。末尾が最新なので何がいま書かれているか一目瞭然です。-hは人間が読みやすいサイズ表示(KB/MB)。cat laravel.log— ファイル全体を出力。小さいファイルのときのみ。数MB以上ではターミナルが重くなります。tail -n 100 laravel.log— 末尾100行だけ。最新のエラーを素早く見るのに最適。行数は好みで変えてOK。tail -f laravel.log— リアルタイム追従。新しいログが書き込まれるたびに端末に流れてきます。ブラウザで問題動作を再現すれば、その瞬間のログが目の前に流れてきます。Ctrl+Cで停止。head -n 50 laravel.log— 先頭50行だけ。起動時のログを見るときに使います。wc -l laravel.log— 行数確認。10万行を超えているなら即grepへ進みましょう。
mv laravel.log laravel.log.oldで退避させて空ファイルを再生成すると、次の再現時にキレイな新規ログだけを見られます。古いログは保存したまま進められます。
ファイルが長いときはtailだけでは足りません。grepはファイル中の特定文字列を含む行だけを抜き出すコマンドで、ログデバッグの中核ツールです。
grep -i error laravel.log— 「error」を含む行をすべて出力。-iは大文字小文字を無視するので、"Error"・"ERROR"・"error"がすべてマッチします。grep -in "fatal\|exception" laravel.log— 「fatal」または「exception」を含む行を行番号付き(-n)で出力。複数キーワードは\|でOR結合します。grep -A 5 -B 2 "SQLSTATE" laravel.log—SQLSTATEを含む行を見つけ、前2行(-B 2)と後5行(-A 5)の文脈も一緒に出力。例外のスタックトレースと併せて見たいときに最高に便利。grep "2026-04-25 15:4" laravel.log— 特定時刻帯(15時40分台)だけ抜粋。ステップ1でメモした時間と合わせて範囲をぐっと狭められます。grep -c "production.ERROR" laravel.log— マッチ行の件数だけを数える。「このエラーはどのくらいの頻度で出ているのか」を知るとき。tail -f laravel.log | grep -i error— リアルタイム追従+フィルタ。tailで流れるログのうちerrorを含む行だけを画面に残します。
典型的な探索フロー — grep -i errorで全体像を見る → 目を引くメッセージを選びgrep -A 10 "そのメッセージ"で前後の文脈を確認 → 出てきたファイルパスと行番号をメモする。
grep ... | lessでページ単位に送るか、grep ... > /tmp/out.txtでファイルに保存してリモート管理のコードエディタで開きましょう。Alpineでもlessは標準で使えます。
grepで捕まえたエラー行には、通常ファイルパスと行番号(例:/var/www/html/app/Services/Order.php:127)が添えられています。これをもとに直接修正に入ります。
- ターミナルを畳み、ファイルエクスプローラーのパス入力欄に
/var/www/html/app/Servicesを貼り付けてEnter。 - 該当ファイルをダブルクリックすると構文強調付きのコードエディタが開きます。行番号を頼りに問題部分を直し、[保存]を押せばサーバーに即反映されます(再デプロイ不要)。
- ターミナルを再度開き、
tail -f /var/www/html/storage/logs/laravel.logでリアルタイム追従をONにした状態で、ブラウザで問題動作をもう一度再現します。 - 同じエラーが再発するか見て、出なければCtrl+Cでtailを停止して完了。別のエラーが出たならステップ5に戻ってさらに絞り込みます。
一時的にデバッグログを増やしたいとき — 疑わしい箇所のコードに\Log::info('[debug] ' . json_encode($variable));を1行入れて保存 → 動作再現 → grep "[debug]" laravel.logで値を直接確認 → 原因が分かったらLog::info()の行を消す、という流れが最も安全です。
Log::info・dd()・var_dump()は作業が終わったら必ず消すかコメントアウトしてください。残しておくと実ユーザーのリクエストごとにログが膨張し、dd()が残っているとその機能が真っ白な画面で落ちます。
最終チャレンジ · VS Code + AI(Claude/CodexをMCP接続)で作業し、ローカル → stage → 本番の3段デプロイ
これまで身につけたすべての機能が一堂に集まる総仕上げのガイドです。VS Code内でClaudeやCodex(MCP接続)に自然言語で作業を依頼し、まずローカルテストサーバで結果を確認します。問題なければボタン1回でstageサーバへコードとDBを同期し、本番に近いドメイン環境で再検証、最後に本番(prod)へデプロイしてエンドユーザに公開する —— 業界標準のワークフローを最初から最後まで一周してみます。
作業1サイクル —— VS Codeエディタ ⇄ Claude/Codex(MCP) ⇄ ローカルプレビュー
AIがコードを直接書く時代、人の役割は「正確に依頼し、結果を検証する」ことです。VS Codeのチャットパネルに自然言語で依頼するとClaude/CodexがMCP経由でプロジェクトファイルを直接読み書きし、変更はすでに動いているvite dev / php artisan serveで即座にブラウザに反映されます。人は意図通りかを確認し、次の依頼を投げるだけです。
自然言語で依頼(例:「usersテーブルにphoneカラムを追加して、登録フォームに1行増やして」)。結果をブラウザで確認し、次の依頼へ。
(自然言語) コード変更
適用
MCP経由でプロジェクトファイルを直接読み書き。SQLマイグレーション、blade/vue/scss編集、ビルドまで一括。あなたは結果だけ見て判断します。
3段デプロイのパイプライン —— Local → Stage → Production
ローカルの変更をいきなり本番に投げません。途中のstage環境(ドメイン/DB/トラフィック条件が本番に近い)で1回回帰確認してから本番へ。QS DEPLOYタブの[SRC → DST]ボタン1回が1段の移動、コード+資産(assets)+DBがまとめて移動します。
- 自分のPCでvite dev + php artisan serveが自動起動
- 保存→ブラウザ更新が1秒
- AIが入れた変更を最速で検証
- 本番と同じドメイン/DB条件(別ホスト)
- 実データに近い形で回帰チェック
- 他人にリンクを共有してレビュー依頼
- 実ユーザがアクセスするmainサーバ
- Save on Deployで未保存ファイル事故を防ぐ
- デプロイ直後に監視→問題ならSWITCHで即ロールバック
現場の開発チームがほぼ例外なくたどる流れです。変更は小さく、検証は段階ごと。一度に本番に投げると一度に壊れます。
- ローカルは速い。保存→更新が1秒。意図通り動くかを最初に見る場所。
- stageはドメイン/DB/トラフィック条件が本番に近い。「自PCでは動くがサーバで動かない」を捕まえる最後の網。
- 本番(prod)は実ユーザが触る場所。ここで初めて見る問題はそのままユーザのクレームに直結します。
今日はこの3段を最初から最後まで一周します。作業自体はVS Code内でClaudeやCodexに自然言語で依頼して進めます。人の役割は1行ずつコードを打つことではなく、意図を明確に伝え、結果を検証し、次の段に送るかを判断することです。
道具に慣れるほど本作業が速くなります。このステップは5分の一回投資がすべてです。
- QuickStart Webで自分のプロジェクトのパッケージダウンロード→ ZIPを展開してVS Code [File > Open Folder]。
- 下部にQUICKSTARTパネルが自動で現れ、
.envのfingerprintでログインフォーム無しでサーバ接続。 - UTILタブの最下部の[🚀 SMART SETUP]クリック →
composer dump-autoload → npm install → vite buildが自動実行。終わるとvite devとPHP組み込みサーバが両方稼働中になります。
このタイミングでブラウザでhttp://localhost:<port>を開けば自分のプロジェクトがそのまま動きます。ここがスタートです。
2つの道があり、通常は両方併用します。
- ① VS Codeチャットパネル + MCP —— Claude(またはCursor、Copilot Chat、Codex CLI)にMCPサーバを接続しておくと、チャットに「usersテーブルにphoneカラムを追加して、登録フォームに1行増やして」のように自然言語で依頼できます。AIが直接SQL作成、blade/vue/scss編集、ビルドまで一括。
- ② UTILタブのAIボタン —— コードを選択してUTIL → AIグループの[CODE REVIEW] · [REFACTOR] · [EXPLAIN] · [i18n TS]のいずれかをクリックすると、プロジェクト文脈付きのプロンプトが生成されます。これをそのままClaude/Codexに投げると作業品質がぐっと上がります。
うまく依頼するコツ —— 「何を、どこに、どんな形で」の3つを明確に。例:「/admin/usersページでphoneカラムをemailの直後に表示し、空値なら\"-\"を出して」。これならAIが迷いません。
AIがコードを保存した瞬間、vite devがホットリロードでブラウザを更新します。.blade.php·.scss·.vue·.jsのほぼすべてが保存即反映。PHPバックエンド変更はphp artisan serveがそのまま受け取ります。
- ブラウザで実画面を直接確認 —— 意図した位置、意図した動作、意図した形か。
- F12コンソールに赤いエラーが無いか一度ざっと。コンソールが綺麗な状態で次に進む。
- UTIL → SYSTEM → [CLEAN CACHE]でLaravelキャッシュを一度クリアすると view/route 変更が綺麗に反映されます。
意図と違えばAIに短く再依頼 —— 「さっきのphoneカラムを郵便番号の上に移して」 —— と再更新。1分以内に1サイクル回れば標準速度です。
ローカルが通ったらstageへ送ります。
- VS Code下部パネルのQS DEPLOYタブへ。
- 左サイドバーでSource = L(Local)選択、Destination = stageチェック。
- 各ノードの[CONNECT]·[TEST CONFIG]を1回押し、本当に接続できるか確認。赤表示があれば.envのhost/port/DBアカウントから点検。
- 中央の[SRC → DST]ボタンクリック。右の[Save on Deploy]トグルがONか念のため確認 —— ONなら開いている全ファイルが自動保存後にデプロイ開始。
- ログビューアでコード+資産(画像·ビルド出力)+DBスキーマ/データが順にstageへ流れていく様子がリアルタイムに表示されます。
完了したらstageドメインをブラウザで開きます。コード変更だけでなく、新しく作ったphoneカラムがstageのDBにも入ったかを必ず合わせて確認します。
stageは本番の鏡です。ドメインがstage用なだけで、コードとDBは本番に行くものそのまま。
- 実ドメインでアクセスして変更箇所を自分でもう一度使ってみる。ローカルでは見えないキャッシュ·CDN·セッション問題がここでよく出ます。
- 他人にリンクを共有して一度見てもらう。本人は意図を知っているために見えないものが、他人にはすぐ見えます。
- QS DEPLOYタブの[DIFF]でstage ↔ ローカルの差分を見る。差があれば誰かがstageを直接編集した痕跡 —— 本番デプロイ前に整理します。
- [BROWSER]でstageサーバの実ファイルツリーを開いて怪しいファイルを確認できます。
もし回帰が見つかった —— ローカルに戻ってAIに再依頼 → ステップ4に戻る → 通ったら再びステップ5へ。ここでもう1周回るコストは本番事故1回より圧倒的に安いです。
stageが通ったら最後です。本番デプロイは操作はステップ5と同じですが、実ユーザに即座に見える違いがあります。
- QS DEPLOYタブでSource = stage(または同じコードのL)、Destination = main(本番ノード)選択。
- [Save on Deploy]トグルがONか今一度確認。普段からONにしておくのが安全。
- [SRC → DST]クリック。ログビューアで進行を最後まで見守る —— 5xxや赤線があれば即中断。
- 完了したら本番ドメインを直接開き、変更箇所と変更していない主要フロー(ログイン·決済など)を併せて一度回してみます。
- 問題があればSourceとDestinationを[SWITCH]で入れ替え、直前のstage状態を本番に戻す「ロールバック」フローを即実行できます。
ここまで一周できたら —— VS Code → Claude/Codex(MCP) → Local → Stage → Prodの正攻法ワークフローを完走したことになります。以後の変更は同じ道をより速く繰り返すだけです。