OpenMake01
開発状況
8月31日から9月3日までにGitHub mainへ45コミットが積み上がり、前週の仕上げ分である1.35.0・1.35.1を月曜未明に切った後、1.36.0から1.40.0まで7つのリリースが出ました。3つの流れが重なった週です。受け付けるだけで本文を読めなかったHWP・HWPX・HMLの公文書を読めるようにし、その過程でコンテキスト超過を一時的な障害として案内していた問題とトークンの過小推定が見つかり、併せて修正しました。ローカルの既定モデルをqwen3.8-27bへ切り替えるにあたり、静的カタログではなくゲートウェイからモデルを自動発見するようにし、新モデルの点検で見つかったサンプリング既定値・推論の保持・画像総量の問題を続けて手当てしました。外部モデル側ではhasaとB.AIをBYOKプロバイダーとして追加し、無料キーの分あたり上限で討論・ディープリサーチが崩れないようプロバイダー別の同時実行数と429バックオフを設け、推論の強さ3段階が外部モデルにも実際に伝わるようにしました。その間にapps/apiのセキュリティレビューで出たhigh 3件・medium 1件・low多数を2日で閉じ、ルーティングのゴールデンセットを150件へ広げてルーティング精度を77.5%から100%へ引き上げ、nightlyの実モデル評価を運用Macに載せました。
- 韓国の公文書を読めます。.hwpと.hwpxは以前からアップロード許可リストにありましたが、どの抽出器のリストにもなく、受け付けるだけで本文を読めない状態でした。純粋JSパーサーのkordocでHWP 3.x/5.x・HWPX・HWPMLを抽出し、.hmlのアップロードを開き、Agent Taskのサンドボックスイメージにkordocをビルド時に組み込んで公文書の生成やテンプレート記入までできるようにしました（1.36.0）。デプロイ直後に二層の不具合が現れました。コンポーザーの原本送信リストにhwp系が抜けていたため363KBの文書が壊れたテキストとして上がりコンテキストを超え、その失敗が「外部LLMプロバイダーの一時的な障害」と案内されて再試行しても同じ結果でした。送信リストをバックエンドの抽出リストと対にし、コンテキスト超過はCONTEXT_TOO_LARGEとして分離して7ロケールで添付を減らすよう案内し、再試行は勧めないようにしました。
- トークン推定の盲点を実測で確認し、狭めました。文字ベースの推定は韓国語の散文やコードには保守的ですが、JSONログは61%、base64は36%、hexは30%まで過小推定し、context-fitの安全網をそのまま通していました。重み調整では覆えないことを確認した上で、推定値が有効コンテキストの半分を超える要求だけvLLMの/tokenizeで正確に再計算し、補正係数を切り詰めにも同じく適用します。通常の会話はしきい値に届かないため追加呼び出しはありません。ターン予算の判定でHWP拡張子が抜けていた潜在不具合も同じ点検で取り除きました。
- ローカルの既定モデルがqwen3.6-35b-a3bからqwen3.8-27bへ変わりました（1.38.0）。DGXがモデルを入れ替えた後もアプリは古い名前に縛られ、UI・カタログ・capabilityが実体とずれていました。静的カタログの1行が一覧の唯一の出処だったためです。今は起動時と周期プローブがLiteLLMの/model/infoを読んでローカルモデルを発見し、静的リストはゲートウェイに届かないときのフォールバックとしてだけ残ります。新モデル点検の後続として、サンプリングを指定しないローカル呼び出しにthinking ON/OFF別の公式推奨値を入れ、ディープリサーチの下位呼び出し・討論参加者・構造化回答などメタ呼び出し10か所にthink:falseを明示し、推論レベル未指定時のフォールバックを最大推論からmediumへ下げました。ツールループではassistantのreasoning_contentを次ターンへ保持し、ツール呼び出し5ターンの間、毎ラウンド直前の推論を失って考え直していた無駄をなくしました。vLLMが発行したtool_call idを合成値で上書きせず、要求あたりのプロンプト画像総量をvLLMの上限8枚に合わせて9枚目で400が返る経路を塞ぎました。
- 外部モデルを実際に使えるようにしました。Open AI Service Hub（hasa）とB.AIをBYOKプロバイダーとして追加し、B.AIは45モデルを残高0のキーで全て呼び出して無料の5種だけカタログに載せました（1.38.0・1.39.0）。討論とディープリサーチで明示的に選んだ外部モデルが実行不能なとき静かにローカルへフォールバックしていたのをエラーとして表面化し、外部モデルを無視するという誤ったフロントの案内を訂正しました。ところが専門家5人の並列呼び出しはB.AI無料キーで5/5、hasa開発キーで3/5が429で終わりました。外部実行クライアントをProxyで包み、プロバイダー別セマフォとRetry-Afterを尊重する429指数バックオフを置き、ディープリサーチのfan-out同時実行数とタイムアウトをプロバイダーのヒントに合わせ、SDKの盲目的な再試行を0にしてタイムアウトに倍率を適用しました（1.40.0）。入力欄の推論の強さ3段階はこれまでローカルとChatGPT OAuthでしか有効でなかったところ、OpenAI互換の外部プロバイダーにもreasoning_effortとして送られ、推論トークンが実測264から61へ減りました。ヒューリスティックで推定したcapabilityキャッシュがconfigの実測値を隠してvision・thinkingを拒否していた問題と、mediumを400で拒否するglm-5.3の強さマップも訂正しました。
- 9月2日のapps/apiセキュリティレビューの結果を2日で閉じました（1.39.0・1.40.0）。high 3件は、認証済みなら誰でもシステムスキルを上書きできた保存型プロンプトインジェクション、自分のスキルを共有産業エージェントへ割り当てられた経路、他人のuserIdでpush購読を登録して通知の写しを受け取れた問題でした。push所有者をreq.userに固定する際、Web pushが実は一度も配信されていなかった不具合も併せて閉じました。続いて、バンドルidさえ分かれば他人のprivateバンドルを導入できたIDOR、露出時点にしか掛かっていなかった高リスクMCPツールのロールゲートを実行経路にも強制、CSV数式インジェクション、他人のMCPサーバー状態照会のオラクル、所有権検査の空値通過、初回セットアップの管理者競合を処理しました。多層防御として{{env.KEY}}の位置引数の秘密をargvに埋め込まずsh変数参照で渡し、同一ホストの別アカウントがpsで読めないようにし、REST画像の上限、pushエンドポイントのホスト許可リスト、ユーザーサンドボックスのrealpathに基づくシンボリックリンク脱出の遮断を加えました。
- サンドボックスとMCPの運用姿勢を固めました。外部アーキテクチャレビューが指摘したsecure-by-defaultは、コードの既定値を変えずに起動時の姿勢点検と初回セットアップでの自動有効化で達成しました。dockerのないデプロイで外部MCPが原因表示なく全滅しないためです。readonly rootfsへの切り替え本番でuvxベースのサーバー2種だけが全滅した原因をツールvenvの経路に見つけてキャッシュボリュームへ移し、アプリ再起動3回を生き延びた孤児コンテナにはrole・pid・serverIdのラベルを付けて、起動時に所有プロセスが死んだものだけを回収します（1.37.0）。再開用に生きているべきタスクサンドボックスはラベルのスコープで触れません。v2移行を終えたMCP v1 SDKは、デプロイ済みdistに参照がないことを確認して削除しました。
- 評価がゲートになりました。ゴールデンセットを50件から150件へ広げ、運用60日の分布を匿名化して反映するとルーティング精度は93.3%から77.5%へ下がり、これがルーター改善のバックログでした。失敗27件を語彙不足17件とトピックブースト誤発動10件に診断し、24エージェントにキーワード70個を補強し、「짜줘」がプログラミングへ流れていたパターンを狭めて100%へ引き上げ、しきい値を0.5から0.9までratchetしました（1.37.1）。nightlyの実モデル評価を運用Macに載せると、正常な拒否文が禁止語に掛かり、韓国語の拒否が英語の標識を外すラベル不具合が現れて修正し、偽のクリンゴン語で応じるモデルの失敗は品質シグナルとして残しました（1.37.2）。ルーティング・TTFTの日次集計はログ経路の移転後に毎日空のレポートだけ積んでいたのをOMK_LOG_DIRで復旧し、CIゲート16段階が全て成功しながら25分で取り消されていたjob上限を35分へ上げ、リリースノートから抜けた項目を手で補正してその教訓をCLAUDE.mdに残しました。1.40.0以降のツールループ推論保持とローカルプロバイダーのresponseFormat転送はまだリリース前です。
02
週次記録の再構成方法
この期間に一致するローカルClaude Codeプロジェクトセッションは見つかりませんでした。そのためGit履歴が証明できる内容だけを記載します。
確認できるClaude Codeのメインセッション、明示的に連結された子セッション、リポジトリのGit履歴を全件確認しました。セッションは意図と調査を説明し、実際に反映されたコードはGitを最終根拠としました。
今週は進行中です。コミット数と内容は監査基準日の2026年9月4日05:25（KST）までです。
03
チームの位置づけとプロジェクトの役割
OpenMake Teamはコミュニティチーム、openmake_llmはソフトウェアプロジェクト、OpenMakeは製品名です。非開発者のMakerであるriskpwがバイブコーディングでopenmake_llmを主導し、プロの開発者rockyが開発を支援しています。
根拠資料