1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@tazyamah(Suzuki Tatsuya)

令和時代の平成時代延長型Webフレームワーク「Hinoki」の紹介 — RailsライクにADB + PL/SQLでフルスタックを完結させる

1
Posted at

はじめに

Oracle DBとPL/SQLやRailsライクなフレームワークでWebアプリを作っていた平成のSIerの皆さん、こんにちは。
そしてADBやLLMに触れるようになった令和の皆さん、こんにちは。

本記事では、ちょっと変わったコンセプトのWebフレームワーク Hinoki(檜) を紹介します。ひとことで言うと、令和時代の平成時代延長型Webフレームワークです。

平成の頃に現場で多く書かれていた(かもしれない)「PL/SQL + ORDSベースのWebアプリ」という構成を、令和のOCI Autonomous Database(ADB) の上に、Railsライクな読みやすいDSLを載せて蘇らせる、という趣味全開のプロジェクトです。

Hinokiとは

Hinokiは、OCI Autonomous Database(ADB)だけで完結するフルスタックWebフレームワークです。
堅牢な土台という意味を込めて、Claude Codeが命名しました＾＾；

  • ORDS(Oracle REST Data Services)がHTTPサーバー → Web/APサーバー不要
  • PL/SQLがアプリケーションロジック(MVC)
  • Oracle Databaseがデータストア + テンプレート + セッション

Ruby風の .hk DSLで記述し、トランスパイラでPL/SQLに変換してADBにデプロイします。

.hk ファイル ──→ [トランスパイラ] ──→ PL/SQL ──→ ADB
                                        ↑
.sql ファイル ──────────────────────────┘ (そのまま)

構成図としてはこれだけ。
Webサーバーもアプリケーションサーバーもキャッシュサーバーも、ADBひとつですべて担います。

なぜ令和時代の平成時代延長型なのか

平成的な部分

  • Oracle DB + PL/SQLで業務Webを書くノリ
  • サーバサイドレンダリング主体のテンプレート
  • ORDSがHTTPを捌く構成(昔のmod_plsqlの令和版)

令和的な部分

  • OCI Autonomous Databaseへのデプロイ前提(サーバ管理不要・自動スケール)
  • Railsライクな宣言的DSL(validates, has_many, scope など)
  • AIコード生成を使う上でも人の目による目視レビューは見やすいほうが良き

「PL/SQLはもう書きたくない……でもOracle DBの堅牢さとADBの運用コストゼロ感はほしい」
そんな令和のエンジニアのための、平成の資産を活かす延命&アップデートフレームワークです。

推しポイント

1. ADB任せのスケーリング — インフラを考えなくていい

HinokiアプリのランタイムはADBです。つまり、スケーリング戦略の大部分をADBに丸投げできます。

  • CPU・ストレージの自動スケーリング(Auto Scaling) → ADBの機能
  • 高可用性・バックアップ → ADBの機能
  • パッチ適用・アップグレード → ADBの機能(Autonomousなので)
  • HTTPエンドポイント → ORDSが最初から有効

Web/APサーバーがないので、スケールアウト時に考えるべきことがほぼないのです。
「ロードバランサの設定がー」「セッションの共有がー」「オートスケールのトリガがー」という議論が消滅します。セッションもDBに乗っているので、そもそも分散も何もありません。

さらに、OCI Always Free枠のADBでも動きます。個人開発や検証用途なら実質無料です。

2. Railsライクな読みやすいDSL — AIコード生成時代のレビュー性

.hk ファイルは、PL/SQLを書いたことがある人でもない人でも、読んで意図がわかることを重視しています。

例えばモデル定義:

# app/models/article.model.hk

model Article
  table :articles

  permit :title, :body, :author, :published

  validates :title, presence: true, length: { max: 500 }
  validates :body,  presence: true

  has_many   :comments, foreign_key: :article_id
  belongs_to :category

  scope :published, -> { where "published = 1" }
  scope :recent,    -> { order "created_at DESC".limit 10 }

  before_save :set_defaults

  def set_defaults
    self.view_count = 0
  end
end

コントローラもこの通り:

# app/controllers/articles.controller.hk

controller Articles
  before_action :require_login, except: [:index, :show]

  def index
    @posts = Article.published.paginate(params[:page])
    render "articles/index"
  end

  def create_action
    @article = Article.new(permit(:title, :body, :author))
    if @article.save
      redirect_to "/articles/#{@article.id}", flash: "作成しました！"
    else
      render "articles/new"
    end
  end
end

これが同等のPL/SQLパッケージに展開されると、数倍のコード量になります。
「AIに雑に書かせた500行のPL/SQLを人間が目視レビューする」のと、「AIが書いた30行の .hk を人間が目視レビューする」のでは、レビューの精度も速度も桁違いです。

AIに書かせる前提でも、人間が読み書き・レビューしやすい形に言語を設計しておくことは依然として重要で、Hinokiはそこを意識しています。

3. トランスパイル型なので実行時ロスなし

Hinokiはランタイム解釈型ではなくトランスパイル型です。
.hk ファイルはデプロイ時にPL/SQLへ一度変換され、ADBにはその生成済みPL/SQLパッケージが配置されます。

つまり、

  • 実行時にDSLを解釈するオーバーヘッド = ゼロ
  • SQLの発行経路 = 生PL/SQLと同等
  • 最適化 = Oracle Optimizerがそのまま効く

「読みやすい記法を使うと遅くなる」というトレードオフが基本的に発生しません。
「開発時の人間向けレイヤ」と「実行時のDB向けレイヤ」がきれいに分離されているのが強みです。

4. .hk と .sql の共存ができる

すべてをDSLで書く必要はありません。

app/
├── controllers/
│   ├── articles.controller.hk      ← DSLで書いた軽量版
│   └── analytics_controller.sql    ← 複雑な集計は生PL/SQL
├── models/
│   ├── article.model.hk            ← DSL
│   └── analytics_model.sql         ← ウィンドウ関数多用で生SQL

hinoki deploy が拡張子を見て自動判別します。
さらに、.hk の中でも複雑なロジックは raw_plsql <<~SQL ... SQL で生PL/SQLブロックを埋め込めます。

  • 標準的なCRUD → .hk でサクッと
  • ウィンドウ関数やCONNECT BY、分析関数まみれの重い処理 → .sql で全開放

既存のPL/SQL資産をそのまま持ち込めるので、レガシー移行の敷居も低めです。

5. 構成がシンプル = 障害点が少ない

  • Webサーバー → なし(ORDS内蔵)
  • APサーバー → なし(PL/SQL)
  • キャッシュサーバー → なし(DB内)
  • セッションストア → なし(DB内)
  • 認証基盤 → Oracle DBユーザー/ORDSで完結可能

コンポーネント境界が少ないということは、監視対象も、障害時の切り分け対象も、バージョン整合性を取る対象も少ないということです。個人開発〜小中規模の業務アプリでは、これは大きなメリットです。

6. DBとアプリケーションの距離がゼロ

ロジックがDBの中で動くので、

  • N+1問題が構造的に発生しにくい
  • トランザクション境界が極めて明確
  • ネットワーク往復コストがない

データ集約的な業務アプリでは、Active Record的な抽象化をしつつDB内完結という組み合わせは意外と合理的です。

クイックスタート

# 1. 新規アプリ作成
hinoki new myblog
cd myblog

# 2. ADB 接続情報を設定(対話形式)
hinoki db:init

# 3. フレームワークを ADB にインストール(初回のみ)
hinoki install

# 4. scaffold で CRUD 一式を生成
hinoki generate scaffold post title:string body:text author:string published:boolean

# 5. マイグレーション実行
hinoki migrate

# 6. ルーティング
cat > config/routes.hk <<'EOF'
routes "myblog" do
  root "posts#index"
  resources :posts
end
EOF

# 7. ADB にデプロイ
hinoki deploy

この後、

https://<your-adb>.adb.<region>.oraclecloudapps.com/ords/myblog/posts

にブラウザアクセスすれば、Rails風の scaffold で生成されたCRUD画面がもう動いています。
ロードバランサもECSもKubernetesも出てきません。 ADB一個です。

マイグレーションとテンプレート

マイグレーション(Rails風)

migration "create_articles" do
  create_table :articles do
    string    :title, null: false, limit: 500
    text      :body
    string    :author, limit: 200
    boolean   :published, default: false
    integer   :view_count, default: 0
    index     :published
    index     [:author, :published]
  end
end

id, created_at, updated_at は自動付与されます。

テンプレート(Liquid風 + パイプフィルタ)

<!-- app/views/articles/index.html -->
<h2>記事一覧</h2>

{% for post in posts %}
<article class="hinoki-card">
  <h3><a href="/articles/{{ post.id }}">{{ post.title }}</a></h3>
  <p class="meta">
    {{ post.author | default "匿名" }} ·
    {{ post.created_at | time_ago }} ·
    閲覧数: {{ post.view_count | number_format }}
  </p>

  {% if post.published %}
    <span class="badge green">公開中</span>
  {% else %}
    <span class="badge gray">下書き</span>
  {% endif %}

  <p>{{ post.body | truncate 200 }}</p>
</article>
{% endfor %}

| truncate 200 | time_ago | number_format のようなパイプフィルタが最初から用意されていて、ビュー側にロジックをほぼ書かずに済みます。

こんな人・用途におすすめ

  • OCIのAlways Free枠で個人アプリを動かしたい人(運用費ゼロ)
  • 平成のOracle DB/PL/SQL資産を持っていて、令和のモダンな書き方でリファクタしたい現場
  • 小〜中規模の社内業務Webアプリ(在庫、受発注、簡易CRM、社内ポータル など)
  • インフラに時間をかけたくない個人開発者・スモールチーム
  • AIにコードを生成させつつ、人間のレビューも回したいチーム

逆に、以下のようなケースには向きません:

  • 大規模SNSのような、RDB外のスケールを強く求められる用途
  • リアルタイム双方向通信(WebSocket)主体のアプリ
  • 複数DB(Oracle以外)を跨ぐ必要があるシステム

まとめ

Hinokiは、「令和のADB」と「平成のPL/SQL文化」をRailsライクな皮で包んだフルスタックWebフレームワークです。

  • ADBに乗せるだけでスケーリングの悩みが消える
  • Rails風DSLで人間にもAIにも扱いやすい
  • トランスパイル型なので実行時ロスはほぼゼロ
  • .hk と .sql が共存できるのでレガシー資産も活かせる
  • コンポーネントが少ないので障害点も少ない

「サーバレス時代」でもなく「クラウドネイティブ時代」でもなく、あえて令和時代の平成時代延長型というポジションに振り切ったフレームワーク。
Oracle DBに馴染みがある方、個人開発でOCI Always Freeを使いたい方、ぜひ一度試してみてください。

それでは、良きADBライフを。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?